public inbox for [email protected]
help / color / mirror / Atom feedFrom: Heikki Linnakangas <[email protected]>
To: Alexey Klyukin <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: [HACKERS] GIT patch review
Date: Wed, 23 May 2007 21:41:52 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>
Alexey Klyukin wrote:
> What about proposition for indexam changes, I can't find any patches there ?
>
> (http://momjian.us/mhonarc/patches/msg00125.html)
That mail is just discussion that lead to the patch below:
> Is the patch for changing amgetmulti to amgetbitmap relevant to the GIT patch ?
>
> This original patch is here:
> http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php
The fundamental change to the indexam API that GIT requires is support
for returning candidate matches. There's two parts to that: the bitmap
index scan API (amgetmulti) and the regular amgettuple API.
Another issue that needs to be dealt with is that as the GIT patch
stands, it doesn't retain the ordering of tuples within a heap page,
which means that they need to be sorted on a page-by-page basis when
returning them to the executor. That's ugly, the way it's implemented
now. To make it less ugly, we'd need support in the amgettuple API to
return tuples in partial ordering.
Since there was discussion on changing the bitmap index API to make it
more efficient for on-disk bitmap indexes, I created a combined patch
that both works nicely with on-disk bitmap indexes, and supports
candidate matches. That's what the amgetmulti->amgetbitmap patch does.
The other part, supporting candidate matches in the amgettuple API
hasn't been done. I posted a design that's in the patch queue ("Indexam
interface proposal"), hoping to have a consensus on that. There was some
discussion on using the candidate matches support for GIN and GiST as
well. IIRC there was no objections to the candidate matches support, but
I haven't written a patch to do that.
A more controversial and invasive change is the support for returning
tuples in partial ordering. If we don't want to do that, we can modify
the main GIT/clustered indexes patch so that it does retain the full
ordering of tuples. It'll degrade much more quickly to a normal B-tree
if tuples are not perfectly ordered on the heap, if tuples are updated
for examply, but it'll be less invasive.
> It doesn't apply cleanly to the cvs head, I can provide necessary changes
> (actually I've sent them and figured there is a nowhere mentioned limit on
> -hackers which is why I'm resending the message without that patch),
Ok, thanks.
> Any other suggestions on reviewing the GIT patch ?
You might want to start by reading the readme:
http://community.enterprisedb.com/git/git-readme.txt
Thanks for looking into this. If you have any questions, just ask.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
--ELM1205175344-27290-1_--
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: [HACKERS] GIT patch review
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox