Re: Experimenting with hash tables inside pg_dump
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2021-10-22T01:09:36Z
Lists: pgsql-hackers
Hi, On 2021-10-21 20:22:56 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > Yeah, that. I tried doing a system-wide "perf" measurement, and soon > realized that a big fraction of the time for a "pg_dump -s" run is > being spent in the planner :-(. A trick for seeing the proportions of this easily in perf is to start both postgres and pg_dump pinned to a specific CPU, and profile that cpu. That gets rid of most of the noise of other programs etc. > I'm currently experimenting with > PREPARE'ing pg_dump's repetitive queries, and it's looking very > promising. More later. Good idea. I wonder though if for some of them we should instead replace the per-object queries with one query returning the information for all objects of a type. It doesn't make all that much sense that we build and send one query for each table and index. Greetings, Andres Freund
Commits
-
In pg_dump, use simplehash.h to look up dumpable objects by OID.
- 92316a4582a5 15.0 landed
-
Fix frontend version of sh_error() in simplehash.h.
- 974aedcea46d 15.0 landed
- 8cee4be6dc93 14.1 landed
- 2e01d050d989 13.5 landed