[OPEN-ILS-GENERAL] search results mystery

[Holly Brennan]

>> Just to clarify - it doesn't matter the the result set is small after the copy location filter is applied. What you need to look at is what the result count would be without the copy location group applied,

Thanks, Kathy. Once I slowed down a bit and reread that IRC conversation I figured that out. (Still haven’t mastered multi-tasking!)

It makes sense! But is still a bummer. It would have been nice to use Copy Location filters to pull up a whole reading list, or all the new books, but it is useful for finding “that octopus book on the Read 15 in ’16 list.”

>>If you did a search with a format filter or a language filter that pulled back 180 records, you wouldn't see the same problem because the bibliographic filters work differently and aren't applied after the core search.

So bib filters are applied before the core search, and “custom” filters are applied after? This is good to know, though I think the only bib filter I could apply that would immediately reduce the results under 1,000 is Music.

Assuming Mike’s comment in IRC (I'll just leave this right here: http://blog.pgaddict.com/posts/performan​ce-since-postgresql-7-4-to-9-4-fulltext<http://blog.pgaddict.com/posts/performance-since-postgresql-7-4-to-9-4-fulltext>) is related, perhaps I’ll wait until I see him in person to dive deeper into any possible solutions for this, because that is link is all gobbly goop to me.

Thanks again, Kathy! Good to hear I’m not alone and somehow screwing up a seemingly basic search filter.

-Holly

From: Open-ils-general [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Kathy Lussier
Sent: Thursday, January 28, 2016 3:51 PM
To: open-ils-general at list.georgialibraries.org
Subject: Re: [OPEN-ILS-GENERAL] search results mystery

Hi Holly,

Just to clarify - it doesn't matter the the result set is small after the copy location filter is applied. What you need to look at is what the result count would be without the copy location group applied, because that particular filter gets applied after the core search. In your example, you were searching for *, which, without the copy location filter, retrieves a very large set. That's what's throwing off your estimated count.

In that IRC discussion, Mike said the same happens with the site and available copies filters. If you did a search with a format filter or a language filter that pulled back 180 records, you wouldn't see the same problem because the bibliographic filters work differently and aren't applied after the core search.

Kathy
On 01/28/2016 06:47 PM, Holly Brennan wrote:
I forgot to mention that there are a total of 180 records (and therefore 180 items, we don’t have many dups) with the Copy Location of HPL Display – Read 15 in ’16, and therefore only 180 records in the Copy Location Group. So the issue is happening even with a tiny search query.

Thanks for sharing, Kathy. I have been seeing this issue for a while (as with our New Books location), but haven’t had the time to really dive in yet. I’m ready now!

-Holly

From: Open-ils-general [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Kathy Lussier
Sent: Thursday, January 28, 2016 1:47 PM
To: open-ils-general at list.georgialibraries.org<mailto:open-ils-general at list.georgialibraries.org>
Subject: Re: [OPEN-ILS-GENERAL] search results mystery

Hi Holly,

I'm a bit fuzzy on the details for this, but we ran across a similar situation a few months ago when using copy location limiters. There is a very brief IRC discussion this issue at http://irc.evergreen-ils.org/evergreen/2015-10-21#i_210396 . I meant to file a bug report, but I never got around it.

Basically, the estimated results count starts to get inaccurate once you hit something like 1,000 results (this is configured locally and could be different on your system.) The copy location limiters are applied after the core search, so, even though the final count is way below that number, your core search without the limiters actually exceeded that number. I'm guessing the same happens with copy location groups.

I'm sure somebody else here could explain better than I just did, but I just wanted to let you know that we've seen this issue too.

Kathy


On 01/28/2016 05:17 PM, Holly Brennan wrote:
I am trying to solve the mystery of “changing” search results when using a Library search filter. For my single-branch library , the Library filter is just different Copy Location Groups.

I can’t find my specific issue on Launchpad, but I’m also not really sure what’s going on. This issue happens with all my Copy Location Groups, but here’s what happens with a specific, basic example:

I have a Copy Location Group consisting of just a single copy location, HPL Display – Read 15 in ’16, in the Location Group named Read 15 in ‘16:

[cid:image001.jpg at 01D159E9.532C9DE0]

When I search using only this “Library” filter, like this…

[cid:image002.jpg at 01D159E9.532C9DE0]

I get these results on page 1, with about 210 results:
[cid:image003.jpg at 01D159E9.532C9DE0]

Jumping to Page 8 of results, and suddenly I have about 115 results:
[cid:image004.jpg at 01D159E9.532C9DE0]

Jumping to Page 10 of results, I have about 92 results:
[cid:image005.jpg at 01D159E9.532C9DE0]

The results are “consistent” in that if I return to page 1 (or any other page), the number of results is the same as the first time I viewed that particular page (Page 1 always says 210, Page 8 always says 115). BUT THEN, an hour later if I search again, the first page says 270 results… consistently.

So my question, I guess, is “What’s the deal?!” Is the interpretation of “about” in the number of search results really THAT elusive?

Help please, and thank you.

-Holly



Holly Brennan
Library Technology Specialist
Homer Public Library, Alaska

hbrennan at cityofhomer-ak.gov<mailto:hbrennan at cityofhomer-ak.gov>
907-235-3180 (main)
907-435-3154 (direct)





--

Kathy Lussier

Project Coordinator

Massachusetts Library Network Cooperative

(508) 343-0128

klussier at masslnc.org<mailto:klussier at masslnc.org>

Twitter: http://www.twitter.com/kmlussier



--

Kathy Lussier

Project Coordinator

Massachusetts Library Network Cooperative

(508) 343-0128

klussier at masslnc.org<mailto:klussier at masslnc.org>

Twitter: http://www.twitter.com/kmlussier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20160129/a8787925/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 28255 bytes
Desc: image001.jpg
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20160129/a8787925/attachment-0005.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 8934 bytes
Desc: image002.jpg
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20160129/a8787925/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 21137 bytes
Desc: image003.jpg
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20160129/a8787925/attachment-0007.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 20345 bytes
Desc: image004.jpg
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20160129/a8787925/attachment-0008.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 19386 bytes
Desc: image005.jpg
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20160129/a8787925/attachment-0009.jpg>