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: (view raw, whole thread or download thread mbox)
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

In response to


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-2017 The PostgreSQL Global Development Group