út 30. 11. 2021 v 20:11 odesílatel Tomas Vondra <tomas.von...@enterprisedb.com> napsal: > > 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.
Thanks a lot for taking over this, improving and pushing! > 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