On Mon, 2012-07-09 at 05:49 -0700, William King wrote:
It looks like putting my sorts AFTER my query like so:
The sort process only happens after all docs are returned and scored.
Including the sort parameters inside sub-queries has no meaning.
clint
{
"query" : { ... },
"sort" : { ... }
}makes a difference in query times when using 2 geo distance
calculations. Is there any reason for this? I was thinking that
perhaps since the sort is after my cached geo distance query the cache
was being using on the second geo distance calculation in the sort
like so:
{
"query" : { geo distance <-- CACHED },
"sort" : { geo distance <-- CACHE USED }}
versus the sort on the top
{
"sort" : { geo distance <-- NO CACHE }
"query" : { geo distance <-- CACHED }
}On Monday, July 9, 2012 5:40:50 AM UTC-7, William King wrote:
I'm trying to use a computed geo distance in several places in
my search (for example, to sort by and to filter by). To avoid
calculating it several times I wanted to use a script field to
calculate and hold the distance and then access it in other
places in my search. Is there a better way of doing this? And,
if not, is it currently possible to do this?For reference, I tried using a geo distance sort and a cached geo distance filter and found that with both search times went up considerably.