Re: KNN-GiST with recheck - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: KNN-GiST with recheck
Date
Msg-id CAPpHfdvEpZAJrMBkNrCguG4fCK5QtZjARPti7LnL5chsSuD=Sg@mail.gmail.com
Whole thread Raw
In response to Re: KNN-GiST with recheck  (Emre Hasegeli <emre@hasegeli.com>)
Responses Re: KNN-GiST with recheck
Re: KNN-GiST with recheck
Re: KNN-GiST with recheck
List pgsql-hackers
On Sun, Sep 14, 2014 at 10:09 PM, Emre Hasegeli <emre@hasegeli.com> wrote:
I added the point to polygon distance operator patch to the open
CommitFest as ready for committer and added myself as reviewer to
both of the patches.

Thanks. 

> Cost estimation of GiST is a big problem anyway. It doesn't care (and
> can't) about amount of recheck for regular operators. In this patch, same
> would be for knn recheck. The problem is that touching heap from access
> method breaks incapsulation. One idea about this is to do sorting in
> another nodes. However, I wonder if it would be an overengineering and
> overhead. In attached patch I propose a different approach: put code
> touching heap into separate index_get_heap_values function. Also new
> version of patch includes regression tests and some cleanup.

While looking it at I found a bug.  It returns the second column
in wrong order when both of the distance functions return recheck = true.
Test script attached to run on the regression database.  I tried to
fix but could not.  searchTreeItemDistanceRecheck function is not
very easy to follow.  I think it deserves more comments.

Fixed, thanks. It was logical error in comparison function implementation.

------
With best regards,
Alexander Korotkov.
Attachment

pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: proposal: plpgsql - Assert statement
Next
From: Peter Geoghegan
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)