http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12478
--- Comment #72 from Robin Sheat <[email protected]> --- (In reply to Katrin Fischer from comment #71) > We currently do it alphabetically - which is kind of ok, but as we pick the > facets quite randomly out of 20 records... Oh, this should be presenting the facets with the most results across the full set of search results. > I understand about not changing behaviour significantly for now, but I think > there are a lot of weirdnesses that we shouldn't translate to Elastic Search > if we can help it. And our facets are quite weird right now. Well, they're probably a bit more sane in ES anyway. > Sorry, I don't understand, what do you mean by "(roughly, but I think mostly > accurate for the scale of results in a Koha system.)"? Oh, just that when you get to many results over a clustered system, after a point it starts estimating the counts. Like google's "Results 1-10 of about 1,200,000", it's an estimate, not an exact count. But for smaller result counts it's going to be pretty exact. > The demo database seems to be quite small and from here it's not very fast, > so wondering about how performance looks for you. Have you done testing with > a bigger database by chance? (100.000+?). We are running into a lot of > never-noticed problems right now with the bigger databases and searching. http://elasticsearch.koha.catalystdemo.net.nz/files/es-search/ Most of the time is spent in Koha::Database. This is something that has to be fixed in general for Koha to use it (alternately, using a persistent environment like Plack where the init only has to happen once.) There is a bit of extra time spent in Catmandu that could be reduced if necessary, we're using it as a fairly thin wrapper over search (as opposed to indexing where it's critical) and it'd be OK to use the elasticsearch libraries directly. However that's a bridge to burn when we get to it. The database I'm using has 8,679 biblios and 14,841 items. So not very large at all. At some stage I might have a look at putting a bigger one in, but that does impact my reindexing time :) > About the number - I think limiting to 10 could be problematic for things > like itemtypes, locations and branches. It could be good to have that > configurable at some point or an option to just show 'all' for some of the > facets. Sure, but is that a search thing or a Koha thing? I mean, putting hooks in to make this possible is certainly a search thing (they don't exist yet), but the decision on how it should be done is out of scope. I have enough problems to worry about as it is :) -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
