Aaron Birkland <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
