Re: Index Tuple Compression Approach? - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Index Tuple Compression Approach?
Date
Msg-id 87bqd8y0w6.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Index Tuple Compression Approach?  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Index Tuple Compression Approach?  (Heikki Linnakangas <heikki@enterprisedb.com>)
List pgsql-hackers
"Heikki Linnakangas" <heikki@enterprisedb.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? 

> It's been discussed before. One big problem is extracting the common
> leading part. You could only do it for text, 

Or for multi-column indexes

I could see this being especially useful if you have some columns in the index
key which are small and some that are quite large. So if you have an event
table with an index on <userid,timestamp> you wouldn't have to store lots of
timestamps on the upper level tree nodes. You would only store them for the
leaf nodes.

> but it should be done in a datatype neutral way.

I wonder if there's an analogous operation for other data types though.
Numeric could store the a value relative to the parent value. Arrays could
store only the elements needed. bytea of course works just as well as text (or
better in the face of i18n).

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


pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: XID wraparound and busy databases
Next
From: Tom Lane
Date:
Subject: Re: XID wraparound and busy databases