Re: On-disk bitmap index patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: On-disk bitmap index patch
Date
Msg-id 28525.1153698215@sss.pgh.pa.us
Whole thread Raw
In response to Re: On-disk bitmap index patch  (Gavin Sherry <swm@linuxworld.com.au>)
Responses Re: On-disk bitmap index patch  (Gavin Sherry <swm@linuxworld.com.au>)
List pgsql-hackers
Gavin Sherry <swm@linuxworld.com.au> writes:
> Is anyone else looking at this patch?

It's on my list of things to look at, but so are a lot of other patches ;-)

A couple of comments after a *very* fast scan through the patch:

* The xlog routines need help; they seem to not be updated for recent
changes in the API for xlog recovery code.

* The hacks on vacuum.c (where it tests the AM name) are utterly
unacceptable.  If you need the main code to do something special for a
particular index AM, define a bool flag column for it in pg_am.

* The interface to the existing executor bitmap scan code is mighty
messy --- seems like there's a lot of almost duplicate code, a lot
of rather invasive hacking, etc.  This needs to be rethought and
refactored.

* Why in the world is it introducing duplicate copies of a lot
of btree comparison functions?  Use the ones that are there.

* The patch itself is a mess: it introduces .orig and .rej files,
changes around $PostgreSQL$ lines, etc.


However, the main problem I've got with this is that a new index AM is a
pretty large burden, and no one's made the slightest effort to sell
pghackers on taking this on.  What's the use-case, what's the
performance like, where is it really an improvement over what we've got?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: Documenting Replication Solutions
Next
From: Tom Lane
Date:
Subject: Re: [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL