Re: sequential scan on select distinct - Mailing list pgsql-performance

From Mischa Sandberg
Subject Re: sequential scan on select distinct
Date
Msg-id 8fh9d.25089$MV5.20638@clgrps13
Whole thread Raw
In response to Re: sequential scan on select distinct  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Tom Lane wrote:
> Ole Langbehn <ole@freiheit.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?

pgsql-performance by date:

Previous
From: HyunSung Jang
Date:
Subject: why my query is not using index??
Next
From: Janning Vygen
Date:
Subject: Re: EXPLAIN ANALYZE much slower than running query normally