Re: Solving hash table overrun problems
От | Tom Lane |
---|---|
Тема | Re: Solving hash table overrun problems |
Дата | |
Msg-id | 27192.1109947966@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Solving hash table overrun problems (Aaron Birkland <birkie@gmail.com>) |
Ответы |
Re: Solving hash table overrun problems
|
Список | 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 по дате отправления: