Fix CatalogTupleInsert/Update abstraction for case of shared indstate.
Add CatalogTupleInsertWithInfo and CatalogTupleUpdateWithInfo to let
callers use the CatalogTupleXXX abstraction layer even in cases where
we want to share the results of CatalogOpenIndexes across multiple
inserts/updates for efficiency. This finishes the job begun in commit
2f5c9d9c9, by allowing some remaining simple_heap_insert/update
calls to be replaced. The abstraction layer is now complete enough
that we don't have to export CatalogIndexInsert at all anymore.
Also, this fixes several places in which 2f5c9d9c9 introduced performance
regressions by using retail CatalogTupleInsert or CatalogTupleUpdate even
though the previous coding had been able to amortize CatalogOpenIndexes
work across multiple tuples.
A possible future improvement is to arrange for the indexing.c functions
to cache the CatalogIndexState somewhere, maybe in the relcache, in which
case we could get rid of CatalogTupleInsertWithInfo and
CatalogTupleUpdateWithInfo again. But that's a task for another day.
Discussion: https://postgr.es/m/27502.1485981379@sss.pgh.pa.us
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/aedd554f84bb3cedb32e6e2a954a70537a4da6b9
Modified Files
--------------
src/backend/catalog/heap.c | 19 +++-----
src/backend/catalog/indexing.c | 69 +++++++++++++++++++++++++-----
src/backend/catalog/pg_depend.c | 6 +--
src/backend/catalog/pg_shdepend.c | 2 +-
src/backend/commands/cluster.c | 11 +++--
src/backend/storage/large_object/inv_api.c | 10 +++--
src/include/catalog/indexing.h | 9 ++--
7 files changed, 84 insertions(+), 42 deletions(-)
