Re: ToDo: KNN Search should to support DISTINCT clasuse?

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:

http://archives.postgresql.org/message-id/CA%2BCSw_uE-RCyQd_bXJNe%3DusrXkq%2BkeFrQrahkc%2B8ou%2BWs4Y%3DVw%40mail.gmail.com

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

In response to

Browse pgsql-hackers by date

  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