Added to TODO:
* Allow index scans to return matching index keys
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php
---
Heikki Linnakangas wrote:
Currently amgettuple returns one
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
IIRC indexes can already ask to have the system recheck conditions on
returned tuples. For example GiST can return more tuples than actually
match. That's what the amopreqcheck column is for in pg_amop.
On Mon, Mar 19, 2007 at 12:23:01PM +, Heikki Linnakangas wrote:
Currently amgettuple returns one matching tuple at a time, in index
order. I'm proposing two changes to add support for
- candidate matches
IIRC indexes can already ask to have the system recheck conditions on
returned
Martijn van Oosterhout wrote:
On Mon, Mar 19, 2007 at 12:23:01PM +, Heikki Linnakangas wrote:
Currently amgettuple returns one matching tuple at a time, in index
order. I'm proposing two changes to add support for
- candidate matches
IIRC indexes can already ask to have the system
Right, except that flag is per operator in operator class, and what I'm
proposing is that the index could pass a flag per tuple in the scan.
That might make sense even for GiST. Sometimes complex compressions is used in
GiST opclasses. If indexing value is rather small then it's stored in
Teodor Sigaev wrote:
Right, except that flag is per operator in operator class, and what
I'm proposing is that the index could pass a flag per tuple in the scan.
That might make sense even for GiST. Sometimes complex compressions is
used in GiST opclasses. If indexing value is rather small
On Mon, Mar 19, 2007 at 04:40:52PM +0300, Teodor Sigaev wrote:
Right, except that flag is per operator in operator class, and what I'm
proposing is that the index could pass a flag per tuple in the scan.
That might make sense even for GiST. Sometimes complex compressions is used
in GiST
Heikki Linnakangas [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
IIRC indexes can already ask to have the system recheck conditions on
returned tuples. For example GiST can return more tuples than actually
match. That's what the amopreqcheck column is for in pg_amop.
Right, except
Interesting. So we'd add a flag to the index tuples in GiST indicating
if the tuple is lossily compressed or not. The compress-function would
set that flag when it performs lossy compression, and gistgettuple would
return it to the caller.
Keys in GiST index may be another type than column on
Given that rechecking requires Expr and state structures, maybe it would
be easier to make the operators RECHECK so the planner does the right
thing now, but make a flag that tells the index scan *not* to recheck
this tuple. That would seem slightly less work and fit better with the
existing
10 matches
Mail list logo
