Re: No merge sort?

"Ron Peacetree" <rjpeace(at)earthlink(dot)net> wrote in message
news:EHIla(dot)19833$ey1(dot)1702921(at)newsread1(dot)prod(dot)itd(dot)earthlink(dot)net(dot)(dot)(dot)
> ""Dann Corbit"" <DCorbit(at)connx(dot)com> wrote in message
>
news:D90A5A6C612A39408103E6ECDD77B829408ACB(at)voyager(dot)corporate(dot)connx(dot)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?