út 30. 11. 2021 v 20:11 odesílatel Tomas Vondra
<tomas.vondra@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