> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Having said all that, there is one situation where this type of approach might > still be useful even after such a fix, and that's KNNGist-style > queries: > > select a,b,c from t order by col <-> constant limit 10; > > In a KNNGist search, there's no provision for the index AM to return the actual > value of the ORDER BY expression, and in fact it's theoretically possible that > that value is never even explicitly computed inside the index AM. So we couldn't > suppress the useless evaluation of <-> by dint of requiring the physical scan > to return that value as a Var. > > Reading between the lines of the original submission at > <CAPpHfdtG5qoHoD+w=Tz3wC3fZ=b8i21=V5xandBFM=DTo-Yg=q...@mail.gmail.com>, > I gather that it's the KNNGist-style case that worries you, so maybe it's worth > applying this type of patch anyway. I'd want to rejigger it to be aware of > the cost implications though, at least for grouping_planner's choices. +1 for improving KNNGist-style queries. Sorry for the late response. Thanks, Best regards, Etsuro Fujita -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
