Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> 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 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.
>
> The reason for attaching the flag to operators is so that the system
> (particularly the planner) can tell *which* conditions need to be
> rechecked, and can prepare the necessary expression infrastructure.
> I dislike the idea of having to be prepared to do that every time
> for every indexscan.
I don't see any big down-side in preparing for that. We'd need to always
store the original index quals in the executor node, like we do now with
recheck-flagged operators, but that doesn't seem too bad to me.
I suppose we would want to keep the existing per-operator recheck-flag
and quals as it is, and add another field like indexqualorig to be used
to recheck tuples amgetnext flags as candidates.
> The notion of having to be prepared to sort
> (according to what?) is even worse.
That we wouldn't need for clustered indexes, if we change the current
design a bit. Either:
* store a sorted list of offsetnumbers for each group, instead of a bitmap,
* or store a bitmap like now, but require that heap tuples in a grouped
index tuple are in cluster order within the heap page.
The first option eats away some of the space savings, the second option
makes clustered indexes to become declustered quicker if there's
out-of-order updates or inserts.
Choosing either option would also reduce the CPU overhead of index
scans, because we could use binary search within a grouped index tuple.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
