Re: No merge sort?
От | Ron Peacetree |
---|---|
Тема | Re: No merge sort? |
Дата | |
Msg-id | AVKla.20090$ey1.1720338@newsread1.prod.itd.earthlink.net обсуждение исходный текст |
Ответ на | Re: No merge sort? ("Dann Corbit" <DCorbit@connx.com>) |
Список | 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 по дате отправления: