Re: Avoid overhead open-close indexes (catalog updates)
Ranier Vilela <ranier.vf@gmail.com>
From: Ranier Vilela <ranier.vf@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers@postgresql.org
Date: 2022-11-15T14:42:34Z
Lists: pgsql-hackers
Em ter., 15 de nov. de 2022 às 04:02, Michael Paquier <michael@paquier.xyz> escreveu: > On Tue, Nov 15, 2022 at 09:57:26AM +0900, Michael Paquier wrote: > > Anyway, multi-inserts are going to be solution better than > > CatalogTupleInsertWithInfo() in some cases, because we would just > > generate one WAL record of N inserts rather than N records with one > > INSERT each. > > Something that you did not consider in the initial patch is that we > may finish by opening catalog indexes even in cases where this would > not have happened on HEAD, as we may finish by doing nothing when > copying the stats or updating them during an analyze, and that's not > fine IMO. However it is easy enough to minimize the cost: just do a > CatalogOpenIndexes() when absolutely required, and close things only > if the indexes have been opened. > I find it very difficult not to have some tuple to be updated, once inside CopyStatistics and the branch cost can get in the way, but I don't object with your solution. > > Then, there are the cases where it is worth switching to a > multi-insert logic as these are going to manipulate more than 2 > entries all the time: enum list addition and two code paths of > tsearchcmds.c (where up to 16 entries can be lined up). This is a > case-by-case analysis. For example, in the case of the enums, the > number of elements is known in advance so it is possible to know the > number of slots that would be used and initialize them. But that's > not something you would do for the first tsearch bits where the data > is built upon a scan so the slot init should be delayed. The second > tsearch one can use a predictible approach, like the enums based on > the number of known elements to insert. > Makes sense. > > So I've given a try at all that, and finished with the attached. This > patch finishes with a list of bullet points, so this had better be > split into different commits, I guess. > Thoughts? > Missed AddRoleMems? Could you continue with CatalogTupleInsertWithInfo, what do you think? regards, Ranier Vilela
Commits
-
Use multi-inserts for pg_ts_config_map
- 63c833f4bdca 16.0 landed
-
Use multi-inserts for pg_enum
- 1ff416121884 16.0 landed
-
Avoid some overhead with open and close of catalog indexes
- 09a72188cd5c 16.0 landed
-
Preserve index data in pg_statistic across REINDEX CONCURRENTLY
- b17ff07aa3eb 14.0 cited