Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Al
Hi,
Here is a patch by Heikki Linnakangas with changes for amgetmulti index
access method to amgetbitmap, which returns all matching tuples at once.
The patch also introduces support for candidate matches. The original
post is here:
http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php
On Mon, 12 Mar 2007, Heikki Linnakangas wrote:
> Here's a patch to change the amgetmulti API so that it's called only
> once per scan, and the indexam adds *all* matching tuples at once to a
> caller-supplied TIDBitmap. Per Tom's proposal in July 2006:
> http://archives.postgresql.org/pgsql-hacker
Simon Riggs wrote:
On Mon, 2007-03-12 at 13:56 -0400, 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
On Mon, 2007-03-12 at 13:56 -0400, 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 b
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
In the second place, this seems to
forever kill the idea of indexscans that don't visit the heap --- not
that we have any near-term prospect of doing that, but I know a lot of
people remain
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
In the second place, this seems to
forever kill the idea of indexscans that don't visit the heap --- not
that we have any near-term prospect of doing that, but I know a lot of
people remain interested in the idea.
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> In the second place, this seems to
>> forever kill the idea of indexscans that don't visit the heap --- not
>> that we have any near-term prospect of doing that, but I know a lot of
>> people remain interested in the idea.
> I'm c
Tom Lane wrote:
I'm really dubious that this is an intelligent way to go. In the first
place, how will you keep the index sorted if you can't determine the
values of all the keys? It certainly seems that this would break the
ability to have a simple indexscan return sorted data, even if the ind
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>> With the unapplied GIT patch, the index doesn't store the index key of
>>> every tuple.
>>
>> I thought the design was to eliminate *duplicate* keys from the index.
>> Not to lose data.
> The idea really is to lose information from the leaf inde
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
This will not work, unless we change the planner --- the original quals
aren't necessarily there in some corner cases (partial indexes, if
memory serves).
This is only for bitmap scans, which *do* always have the o
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This will not work, unless we change the planner --- the original quals
>> aren't necessarily there in some corner cases (partial indexes, if
>> memory serves).
> This is only for bitmap scans, which *do* always have the original
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
The patch also adds support for candidate matches. An index scan can
indicate that the tuples it's returning are candidates, and the executor
will recheck the original scan quals of any candidate matches when the
tuple is fetched f
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> The patch also adds support for candidate matches. An index scan can
> indicate that the tuples it's returning are candidates, and the executor
> will recheck the original scan quals of any candidate matches when the
> tuple is fetched from heap.
14 matches
Mail list logo
