From: | Ants Aasma <ants(at)cybertec(dot)at> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ToDo: KNN Search should to support DISTINCT clasuse? |
Date: | 2012-10-23 20:06:07 |
Message-ID: | CA+CSw_u6P4Js1YHjDiD=GAZhuzMpEVsxv2UJo4FHYv+gCkz0WQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 23, 2012 at 7:25 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> through the end of the input. However, when the HashAgg node is only
> implementing DISTINCT (ON), you can emit each new row as soon as you
> see it, and just make the hash table entry to be certain you don't
> emit it again. I think someone recently submitted a patch along these
> lines and we rejected it because the use case was too thin ... but
> this example is making me think that the use case might not be all
> that thin after all.
If anyone wants to play around, the initial patch is available here:
It looks to me like it should work for the distinct on KNN search case
out of the box. However it needs some planner adjustment for more
complex plans and maybe some refactoring to lose duplication in the
executor to be worth considering committing.
Regards,
Ants Aasma
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2012-10-23 21:34:58 | Re: Extend argument of OAT_POST_CREATE |
Previous Message | Alvaro Herrera | 2012-10-23 18:45:09 | Re: Re: [WIP] Performance Improvement by reducing WAL for Update Operation |