From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Resultset duplicates (was Re: prefix btree implementation) |
Date: | 2005-10-05 20:58:09 |
Message-ID: | 43443E61.7000709@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Qingqing Zhou wrote:
> Oracle 9 uses the grammar like this:
>
> CREATE INDEX ... [ COMPRESS <number_of_first_columns> ]
>
> So it gives the flexibility of choosing optimal number of coulumns to the
> user. The script mentioned in the article guesses the optimal number by
> estimating the size of each choice. But I am thinking we can do it better:
> (1) we don't require that the compressed number of columns on each page are
> the same; (2) when we build up index bottom-up, we can determine this number
> for each page automatically by maximizing the number of items within a page.
Are there any gains in eliminating duplicate values in result-sets? I'd
guess that many/most large result-sets are sorted which should make it
possible to get away with a "same as last row" marker when the whole set
is returned to a client.
Of course, this is where someone turns around and tells me we do this
already :-)
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2005-10-05 22:40:43 | Re: prefix btree implementation |
Previous Message | Gaetano Mendola | 2005-10-05 20:13:21 | Re: wrong optimization ( postgres 8.0.3 ) |