From: | "Ron Peacetree" <rjpeace(at)earthlink(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: No merge sort? |
Date: | 2003-04-12 02:33:04 |
Message-ID: | AVKla.20090$ey1.1720338@newsread1.prod.itd.earthlink.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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?
From | Date | Subject | |
---|---|---|---|
Next Message | Barry Lind | 2003-04-12 02:49:39 | Re: Charset encoding and accents |
Previous Message | Neil Conway | 2003-04-12 02:27:29 | Re: Upgrade to RedHat 9.0 broke PostgreSQL |