Hello, I've rebased and updated the patch a bit. The biggest change is that the performance penalty measured with v1 of this patch is essentially gone in v10. The overhead was due to re-creating IndexInfo information unnecessarily, which I found existed in the estate. I've added a few fields in IndexInfo that are not populated by default but necessary when checking expression indexes, those fields are populated on demand and only once limiting their overhead. Here's what you'll find if you look into execIndexing.c where the majority of changes happened.
* assumes estate->es_result_relations[0] is the ResultRelInfo being updated * uses ri_IndexRelationInfo[] from within estate rather than re-creating it * augments IndexInfo only when needed for testing expressions and only once * only creates a local old/new TupleTableSlot when not present in estate * retains existing summarized index HOT update logic One remaining concern stems from the assumption that estate->es_result_relations[0] is always going to be the relation being updated. This is guarded by assert()'s in the patch. It seems this is safe, all tests are passing (including TAP) and my review of the code seems to line up with that assumption. That said... opinions? Another lingering question is under what conditions the old/new TupleTableSlots are not created and available via the ResultRelInfo found in estate. I've only seen this happen when there is an INSERT ... ON CONFLICT UPDATE ... with expression indexes. I was hopeful that in all cases I could avoid re-creating those when checking expression indexes to avoid that repeated overhead. I still avoid it when possible in this patch. When you have time I'd appreciate any feedback. -greg Amazon Web Services: https://aws.amazon.com
v10-0001-Expand-HOT-update-path-to-include-expression-and.patch
Description: v10-0001-Expand-HOT-update-path-to-include-expression-and.patch
