X-Original-To: pgsql-hackers-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 5FFDF9FA508 for ; Sun, 23 Jul 2006 20:43:47 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 39598-06 for ; Sun, 23 Jul 2006 20:43:42 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 50AB89FA48B for ; Sun, 23 Jul 2006 20:43:42 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k6NNhZqc028526; Sun, 23 Jul 2006 19:43:36 -0400 (EDT) To: Gavin Sherry cc: Jie Zhang , pgsql-hackers@postgresql.org Subject: Re: On-disk bitmap index patch In-reply-to: References: Comments: In-reply-to Gavin Sherry message dated "Mon, 24 Jul 2006 07:21:33 +1000" Date: Sun, 23 Jul 2006 19:43:35 -0400 Message-ID: <28525.1153698215@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.077 tagged_above=0 required=5 tests=AWL, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200607/998 X-Sequence-Number: 86853 Gavin Sherry 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