I noticed that this patch changes HeapSatisfiesHOTAndKeyUpdate() by adding one more set of attributes to check, and one more output boolean flag. My patch to add indirect indexes also modifies that routine to add the same set of things. I think after committing both these patches, the API is going to be fairly ridiculous. I propose to use a different approach.
With your WARM and my indirect indexes, plus the additions for for-key locks, plus identity columns, there is no longer a real expectation that we can exit early from the function. In your patch, as well as mine, there is a semblance of optimization that tries to avoid computing the updated_attrs output bitmapset if the pointer is not passed in, but it's effectively pointless because the only interesting use case is from ExecUpdate() which always activates the feature. Can we just agree to drop that? If we do drop that, then the function can become much simpler: compare all columns in new vs. old, return output bitmapset of changed columns. Then "satisfies_hot" and all the other boolean output flags can be computed simply in the caller by doing bms_overlap(). Thoughts? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers