Skip site navigation (1) Skip section navigation (2)

Re: Solving hash table overrun problems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: apb18(at)cornell(dot)edu
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Solving hash table overrun problems
Date: 2005-03-04 14:52:46
Message-ID: 27192.1109947966@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Aaron Birkland <birkie(at)gmail(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-03-04 14:59:54
Subject: Re: bitmap AM design
Previous:From: Evgen PotemkinDate: 2005-03-04 14:41:44
Subject: Re: SQL99 Hierarchical queries

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group