From: | "Etsuro Fujita" <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "'Alvaro Herrera'" <alvherre(at)2ndquadrant(dot)com>, "'Hitoshi Harada'" <umi(dot)tanuki(at)gmail(dot)com>, "'Alexander Korotkov'" <aekorotkov(at)gmail(dot)com>, "'pgsql-hackers'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch for removng unused targets |
Date: | 2013-08-05 04:58:55 |
Message-ID: | 007101ce9198$7ca4e180$75eea480$@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)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(at)mail(dot)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Gibheer | 2013-08-05 05:20:49 | Re: Patch for reserved connections for replication users |
Previous Message | Amit Kapila | 2013-08-05 03:41:24 | Re: [9.4 CF 1]Commitfest ... over! |