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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | sharath kumar | 2007-03-14 10:35:43 | need help in understanding gist function |
Previous Message | Zeugswetter Andreas ADI SD | 2007-03-14 09:22:17 | Re: Synchronized Scan update |
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-03-14 14:20:14 | Re: LIMIT/SORT optimization |
Previous Message | Jeff Davis | 2007-03-14 08:42:58 | Synchronized Scan WIP patch |