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

Re: [PATCHES] Bitmapscan changes

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] Bitmapscan changes
Date: 2007-03-14 10:22:00
Message-ID: 45F7CCC8.8000307@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> At this point I'm feeling unconvinced that we want it at all.  It's
> sounding like a large increase in complexity (both implementation-wise
> and in terms of API ugliness) for a fairly narrow use-case --- just how
> much territory is going to be left for this between HOT and bitmap indexes?

I'm in a awkward situation right now. I've done my best to describe the 
use cases for clustered indexes. I know the patch needs refactoring, 
I've refrained from making API changes and tried to keep all the 
ugliness inside the b-tree, knowing that there's changes to the indexam 
API coming from the bitmap index patch as well.

I've been seeking for comments on the design since November, knowing 
that this is a non-trivial change. I have not wanted to spend too much 
time polishing the patch, in case I need to rewrite it from scratch 
because of some major design flaw or because someone comes up with a 
much better idea.

It's frustrating to have the patch dismissed at this late stage on the 
grounds of "it's not worth it". As I said in February, I have the time 
to work on this, but if major changes are required to the current 
design, I need to know.

Just to recap the general idea: reduce index size taking advantage of 
clustering in the heap.

Clustered indexes have roughly the same performance effect and use cases 
as clustered indexes on MS SQL Server, and Index-Organized-Tables on 
Oracle, but the way I've implemented them is significantly different. On 
other DBMSs, the index and heap are combined to a single b-tree 
structure. The way I've implemented them is less invasive, there's no 
changes to the heap for example, and it doesn't require moving live tuples.

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

In response to

Responses

pgsql-hackers by date

Next:From: sharath kumarDate: 2007-03-14 10:35:43
Subject: need help in understanding gist function
Previous:From: Zeugswetter Andreas ADI SDDate: 2007-03-14 09:22:17
Subject: Re: Synchronized Scan update

pgsql-patches by date

Next:From: Gregory StarkDate: 2007-03-14 14:20:14
Subject: Re: LIMIT/SORT optimization
Previous:From: Jeff DavisDate: 2007-03-14 08:42:58
Subject: Synchronized Scan WIP patch

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