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

Re: Bitmapscan changes - Requesting further feedback

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bitmapscan changes - Requesting further feedback
Date: 2007-03-21 10:18:07
Message-ID: 4601065F.3060100@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Joshua D. Drake wrote:
> Hackers et al... I was wondering if there are any outstanding issues
> that need to be resolved in terms of the clustered index/bitmap changes?

I have a todo list of smaller items for clustered indexes, but the main 
design issues at the moment are:

1. How to handle sorting tuples in a scan, or should we choose a design 
that doesn't require it?

Should we add support for sorting tuples in scans on the fly, which 
gives more space savings when there's updates, and would also be useful 
in the future to support binned bitmap indexes?

Or should we only form groups from tuples that are completely in order 
on page-level? That makes a clustered index to lose its space savings 
quicker, when tuples are updated. HOT reduces that affect, though. This 
approach would also reduce the CPU overhead of scans, because we could 
do binary searches within groups.

At the moment, I'm leaning towards the latter approach. What do others 
think?

2. Clustered indexes need the support for candidate-matches. That needs 
to be added to the amgetmulti and amgettuple interfaces. I've sent a 
patch for amgetmulti, and a proposal for the amgettuple.

3. Clustered index needs to reach out to the heap for some operations, 
like uniqueness checks do today, blurring the modularity between heap 
and index. Are we willing to live with that? Is there something we can 
do to make it less ugly?

I'd like to get some kind of confirmation first that 1 and 3 are not 
showstoppers, to avoid wasting time on a patch that'll just get rejected 
in the end, and then submit a patch for 2, and have that committed 
before the main patch.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-03-21 12:21:07
Subject: Re: Question: pg_class attributes and race conditions ?
Previous:From: Csaba NagyDate: 2007-03-21 09:47:13
Subject: Re: Stats for multi-column indexes

pgsql-patches by date

Next:From: Gregory StarkDate: 2007-03-21 12:34:12
Subject: Re: patch adding new regexp functions
Previous:From: Magnus HaganderDate: 2007-03-21 09:25:45
Subject: Re: Win32 shmem

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