Re: Index Tuple Compression Approach?

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
Cc: "Dawid Kuroczko" <qnex42(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Index Tuple Compression Approach?
Date: 2007-08-16 07:48:31
Message-ID: 873ayjyl68.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:

> Gregory Stark wrote:
>> "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
>>
>>> That general approach of storing a common part leading part just once is
>>> called prefix compression. Yeah, it helps a lot on long text fields.
>>> Tree structures like file paths in particular.
>>
>> You kind of want to do avoid both the prefix and the suffix, no?
>
> You're much more likely to find common prefixes than suffixes in an
> index page, because of the ordering. I suppose compressing the suffix
> would be useful in some cases as well. You might be better off with some
> generic compression algorithm at that point, though.

Sorry, by "suffix" I don't mean common sufixes, I mean the bits of the key
following the point which discriminates between the left and right side of the
tree.

So for example if you're indexing a text field and have a
tree structure like:

Redhat Fedora Core 7
/ \
Debian Etch (Unstable) Ubuntu hoary

We don't really need the whole of "Redhat Fedora Core 7" in the index node. We
could actually get by with just "R". Everything before "R" is on the left and
everything after "R" is on the right.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 2007-08-16 09:11:51 build farm failures
Previous Message Heikki Linnakangas 2007-08-16 06:48:00 Re: Index Tuple Compression Approach?