Re: CLUSTER and indisclustered - Mailing list pgsql-hackers

From Tom Lane
Subject Re: CLUSTER and indisclustered
Date
Msg-id 15010.1028726802@sss.pgh.pa.us
Whole thread Raw
In response to Re: CLUSTER and indisclustered  (Hannu Krosing <hannu@tm.ee>)
Responses Re: CLUSTER and indisclustered  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers
Hannu Krosing <hannu@tm.ee> writes:
> Now I remembered my original preference for page bitmaps (vs. tuple
> bitmaps): one can't actually make good use of a bitmap of tuples because
> there is no fixed tuples/page ratio and thus no way to quickly go from
> bit position to actual tuple. You mention the same problem but propose a
> different solution.

> Using page bitmap, we will at least avoid fetching any unneeded pages -
> essentially we will have a sequential scan over possibly interesting
> pages.

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.  Again, one could imagine doing that only in
denser areas of the bitmap.

> But I guess that CLUSTER support for INSERT will not be touched for 7.3
> as will real bitmap indexes ;)

All of this is far-future work I think.  Adding a new scan type to the
executor would probably be pretty localized, but the ramifications in
the planner could be extensive --- especially if you want to do plans
involving ANDed or ORed bitmaps.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Don Baccus
Date:
Subject: Re: Why is MySQL more chosen over PostgreSQL?
Next
From: Neil Conway
Date:
Subject: Re: Open 7.3 items