pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Pierre C <lists@peufeu.com>
To: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-performance@postgresql.org, "Kenneth Marshall" <ktm@rice.edu>
Cc: Mladen Gogala <mladen.gogala@vmsinfo.com>
Subject: Re: Select count(*), the sequel
Date: Thu, 28 Oct 2010 11:33:16 +0200
Message-ID: <op.vk94tqzceorkce@apollo13> (raw)
In-Reply-To: <4CC841140200002500036EA2@gw.wicourts.gov>
References: <4CB9D89E.7050701@vmsinfo.com>
	<20101016184443.GA4993@aart.is.rice.edu>
	<AANLkTik6ifMywZq7C1_MiHLafOQ53_OXreHYQdps3GqP@mail.gmail.com>
	<2091.1288133491@sss.pgh.pa.us>
	<op.vk82ubgueorkce@apollo13>
	<4CC841140200002500036EA2@gw.wicourts.gov>

> "Pierre C" <lists@peufeu.com> wrote:
>
>> in-page compression
> How would that be different from the in-page compression done by
> TOAST now?  Or are you just talking about being able to make it
> more aggressive?
> -Kevin

Well, I suppose lzo-style compression would be better used on data that is  
written a few times maximum and then mostly read (like a forum, data  
warehouse, etc). Then, good candidate pages for compression also probably  
have all tuples visible to all transactions, therefore all row headers  
would be identical and would compress very well. Of course this introduces  
a "small" problem for deletes and updates...

Delta compression is : take all the values for a column inside a page,  
look at the values and their statistical distribution, notice for example  
that they're all INTs and the values on the page fit between X+n and X-n,  
store X and only encode n with as few bits as possible for each row. This  
is only an example, the idea is to exploit the fact that on the same page,  
all the values of one column often have lots in common. xid values in row  
headers are a good example of this.

TOAST compresses datums, so it performs well on large datums ; this is the  
opposite, the idea is to compress small tuples by using the reduncancies  
between tuples.



view thread (15+ messages)  latest in thread

Message-ID: <op.vk94tqzceorkce@apollo13>
Permalink:  ../op.vk94tqzceorkce@apollo13/
Also on:    postgresql.org/message-id/op.vk94tqzceorkce@apollo13

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: lists@peufeu.com, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, Kevin.Grittner@wicourts.gov, ktm@rice.edu, mladen.gogala@vmsinfo.com
  Subject: Re: Select count(*), the sequel
  In-Reply-To: <op.vk94tqzceorkce@apollo13>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox