OK,
I've polished the last version of the patch a bit (added a regression
test with update of attribute in index predicate and docs about the new
flag into indexam.sgml) and pushed.
I wonder if we could/should improve handling of index predicates. In
particular, it seems to me we could simply ignore indexes when the new
row does not match the index predicate. For example, if there's an index
CREATE INDEX ON t (a) WHERE b = 1;
and the update does:
UPDATE t SET b = 2 WHERE ...;
then we'll not add the tuple pointer to this index anyway, and we could
simply ignore this index when considering HOT. But I might be missing
something important about HOT ...
The main problem I see with this is it requires evaluating the index
predicate for each tuple, which makes it incompatible with the caching
in RelationGetIndexAttrBitmap. Just ditching the caching seems like a
bad idea, so we'd probably have to do this in two phases:
1) Do what we do now, i.e. RelationGetIndexAttrBitmap considering all
indexes / attributes. If this says HOT is possible, great - we're done.
2) If (1) says HOT is not possible, we need to look whether it's because
of regular or partial index. For regular indexes it's clear, for partial
indexes we could ignore this if the predicate evaluates to false for the
new row.
But even if such optimization is possible, it's way out of scope of this
patch and it's not clear to me it's actually a sensible trade-off.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company