Re: No merge sort? - Mailing list pgsql-hackers

From Ron Peacetree
Subject Re: No merge sort?
Date
Msg-id AVKla.20090$ey1.1720338@newsread1.prod.itd.earthlink.net
Whole thread Raw
In response to Re: No merge sort?  ("Dann Corbit" <DCorbit@connx.com>)
List pgsql-hackers
"Ron Peacetree" <rjpeace@earthlink.net> wrote in message
news:EHIla.19833$ey1.1702921@newsread1.prod.itd.earthlink.net...
> ""Dann Corbit"" <DCorbit@connx.com> wrote in message
>
news:D90A5A6C612A39408103E6ECDD77B829408ACB@voyager.corporate.connx.co
> m...
> > With 80 bytes, you have 2^320 possible values.  There is no way
> > around that.  If you are going to count them or use them as a
> > radix, you will have to classify them.  The only way you will
> > know how many unique values you have in
> > "Company+Division" is to ...
> > Either sort them or by some means discover all that are distinct
> Ummm, Indexes, particularly Primary Key Indexes, anyone?  Finding
the
> unique values in an index should be perceived as trivial... ...and
you
> often have the index in memory for other reasons already.
>
Interesting Note: DB2 and Oracle have switches that turn on a table
feature that keeps track of all the unique values of a field and a
counter for how often each of those unique values occurs.  The
implications for speeding up non write querys involving those tables
should be obvious (again, TANSTAAFL: writes are now going to have the
extra overhead of updating this information)...

Wonder how hard this would be to put into PostgreSQL?



pgsql-hackers by date:

Previous
From: Stu Krone
Date:
Subject: Re: How do you execute a postgresql function from perl?
Next
From: Bob Kline
Date:
Subject: Re: [GENERAL] Upgrade to Red Hat Linux 9 broke PostgreSQL