> From: Tom Lane [mailto:tgl@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
