Re: sequential scan on select distinct

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?

In response to

Browse pgsql-performance by date

  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