Re: Solving hash table overrun problems - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Solving hash table overrun problems
Date
Msg-id 27192.1109947966@sss.pgh.pa.us
Whole thread Raw
In response to Re: Solving hash table overrun problems  (Aaron Birkland <birkie@gmail.com>)
Responses Re: Solving hash table overrun problems
List pgsql-hackers
Aaron Birkland <birkie@gmail.com> writes:
> This also brings up a line of thought I had a while ago on a related
> topic.  Something like a "HashDistinct" might be useful, if it had no
> startup cost.  It would basically be a plan node in the executor that
> would dynamically build a hashtable so that it can pull rows from its
> child node (discarding if they appear in the hashtable) until it can
> pass on a novel row.   I have some reservations about it, though.

We already have that: the planner will use a HashAgg node in this
fashion in some contexts (I think just as one of the ways to do IN,
at the moment).  It's not yet bright enough to consider doing it for
SELECT DISTINCT.  The DISTINCT planning code is old and crufty and
pretty tightly interwired with ORDER BY ... it needs work.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Evgen Potemkin
Date:
Subject: Re: SQL99 Hierarchical queries
Next
From: Tom Lane
Date:
Subject: Re: bitmap AM design