From: | Mischa Sandberg <ischamay(dot)andbergsay(at)activestateway(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: sequential scan on select distinct |
Date: | 2004-10-07 20:00:04 |
Message-ID: | 8fh9d.25089$MV5.20638@clgrps13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom Lane wrote:
> Ole Langbehn <ole(at)freiheit(dot)com> writes:
>
>>>What do you think about the idea of an "UniqueSort" which would do
>>>sort+unique in one pass ?
>
>>This is what oracle does and it is quite fast with it...
> Hashing is at least as fast, if not faster.
>
> regards, tom lane
I got good mileage in a different SQL engine, by combining the
hash-aggregate and sort nodes into a single operator.
The hash table was just an index into the equivalent of the heap used
for generating runs. That gave me partially aggregated data,
or eliminated duplicate keys, without extra memory overhead of the
hash-aggregation node below the sort. Memory was scarce then ... :-)
BTW I'm really puzzled that Oracle is pushing 'index skip scan' as a new
feature. Wasn't this in the original Oracle Rdb --- one of Gennady
Antoshenkov's tweaks?
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2004-10-07 22:50:20 | Re: Data warehousing requirements |
Previous Message | Bill Montgomery | 2004-10-07 18:48:45 | Re: Excessive context switching on SMP Xeons |