Re: CLUSTER and indisclustered

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)tm(dot)ee>
Cc: Curt Sampson <cjs(at)cynic(dot)net>, mark Kirkwood <markir(at)slithery(dot)org>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: CLUSTER and indisclustered
Date: 2002-08-07 14:26:13
Message-ID: 15622.1028730373@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hannu Krosing <hannu(at)tm(dot)ee> writes:
> On Wed, 2002-08-07 at 15:26, Tom Lane wrote:
>> Right. One form of the "lossy compression" idea I suggested is to
>> switch from a per-tuple bitmap to a per-page bitmap once the bitmap gets
>> too large to work with.

> If it is a real bitmap, should it not be easyeast to allocate at the
> start ?

But it isn't a "real bitmap". That would be a really poor
implementation, both for space and speed --- do you really want to scan
over a couple of megs of zeroes to find the few one-bits you care about,
in the typical case? "Bitmap" is a convenient term because it describes
the abstract behavior we want, but the actual data structure will
probably be nontrivial. If I recall Ann's description correctly,
Firebird's implementation uses run length coding of some kind (anyone
care to dig in their source and get all the details?). If we tried
anything in the way of lossy compression then there'd be even more stuff
lurking under the hood.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2002-08-07 14:30:25 Re: [COMMITTERS] pgsql-server/src backend/tcop/postgres.cbacke
Previous Message Manfred Koizar 2002-08-07 14:16:14 Heap tuple header issues