"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes: > On Thu, Apr 24, 2008 at 10:11:02AM +0100, Simon Riggs wrote: >> Index compression is possible in many ways, depending upon the >> situation. All of the following sound similar at a high level, but each >> covers a different use case. > > True, but there is one significant difference: > >> * For Long, Similar data e.g. Text we can use Prefix Compression >> * For Highly Non-Unique Data we can use Duplicate Compression >> * Multi-Column Leading Value Compression - if you have a multi-column > > These are all not lossy and so are candidate to use on any b-tree even > by default. They don't affect plan-construction materially, except > perhaps in cost calculations. Given the index tuple overhead I don't > see how you could lose.
The problem is that while it's easy to see what to do for text (and even then perhaps not so easy in non-C locales) Postgres's extensibility makes it quite tricky to see what to do from there. Perhaps we need a btree procedure which takes two parameters, a "parent" and "child" and returns a compressed value. There would have to be a second procedure to decompress values given their full parent. There are a lot of tricky bits here, like what do you do on leaf pages? You have to be able to follow leaf pages down the chain without consulting their "parent". -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
