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.
> I think that for most use cases just some operators require further sorting > and some of them not. But it could appear one day that some index gives > part of its knn answers exact and part of them inexact. Same happen to > recheck of regular operators. Initially recheck flag was defined in > opclass. But later recheck became runtime flag. I cannot think of an use case, but it makes sense to add the flag to the distance function just like the consistent function if we will go with this implementation. > 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.
knn-gist-recheck-test-multicolumn.sql
Description: application/sql
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers