Hello,
I've rebased and updated the patch a bit. The biggest change is that the performance penalty measured with v1 of this
patchis essentially gone in v10. The overhead was due to re-creating IndexInfo information unnecessarily, which I
foundexisted in the estate. I've added a few fields in IndexInfo that are not populated by default but necessary when
checkingexpression 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
beingupdated. 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
ResultRelInfofound in estate. I've only seen this happen when there is an INSERT ... ON CONFLICT UPDATE ... with
expressionindexes. I was hopeful that in all cases I could avoid re-creating those when checking expression indexes to
avoidthat 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
