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

Re: page compression

From: Jim Nasby <jim(at)nasby(dot)net>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Andy Colson <andy(at)squeakycode(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: page compression
Date: 2011-01-03 09:02:25
Message-ID: 40030A90-48A3-4AD5-AD19-350A90112181@nasby.net (view raw or flat)
Thread:
Lists: pgsql-hackers
On Jan 2, 2011, at 5:36 PM, Simon Riggs wrote:
> On Tue, 2010-12-28 at 09:10 -0600, Andy Colson wrote:
> 
>> I know its been discussed before, and one big problem is license and 
>> patent problems.
> 
> Would like to see a design for that. There's a few different ways we
> might want to do that, and I'm interested to see if its possible to get
> compressed pages to be indexable as well.
> 
> For example, if you compress 2 pages into 8Kb then you do one I/O and
> out pops 2 buffers. That would work nicely with ring buffers.
> 
> Or you might try to have pages > 8Kb in one block, which would mean
> decompressing every time you access the page. That wouldn't be much of a
> problem if we were just seq scanning.
> 
> Or you might want to compress the whole table at once, so it can only be
> read by seq scan. Efficient, but not indexes.

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.

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...
--
Jim C. Nasby, Database Architect                   jim(at)nasby(dot)net
512.569.9461 (cell)                         http://jim.nasby.net



In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2011-01-03 09:03:36
Subject: Re: Recovery conflict monitoring
Previous:From: Jim NasbyDate: 2011-01-03 08:58:26
Subject: Re: contrib/snapshot

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