Skip site navigation (1) Skip section navigation (2)

Re: page compression

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Andy Colson <andy(at)squeakycode(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: page compression
Date: 2011-01-03 15:03:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Jan 3, 2011 at 4:02 AM, Jim Nasby <jim(at)nasby(dot)net> wrote:
> FWIW, last time I looked at how Oracle handled compression, it would only compress existing data. As soon as you modified a row, it ended up un-compressed, presumably in a different page that was also un-compressed.

IIUC, InnoDB basically compresses a block as small as it'll go, and
then stores it in a regular size block.  That leaves free space at the
end, which can be used to cram additional tuples into the page.
Eventually that free space is exhausted, at which point you try to
recompress the whole page and see if that gives you room to cram in
even more stuff.

I thought that was a pretty clever approach.

> I wonder if it would be feasible to use a fork to store where a compressed page lives inside the heap... if we could do that I don't see any reason why indexes wouldn't work. The changes required to support that might not be too horrific either...

At first blush, that sounds like a recipe for large amounts of
undesirable random I/O.

Robert Haas
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Andres FreundDate: 2011-01-03 15:03:58
Subject: Re: [PATCH] V3: Idle in transaction cancellation
Previous:From: Robert HaasDate: 2011-01-03 14:57:27
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group