Refactor pg_dump's tracking of object components to be dumped.
Split the DumpableObject.dump bitmask field into separate bitmasks
tracking which components are requested to be dumped (in the
existing "dump" field) and which components exist for the particular
object (in the new "components" field). This gets rid of some
klugy and easily-broken logic that involved setting bits and later
clearing them. More importantly, it restores the originally intended
behavior that pg_dump's secondary data-gathering queries should not
be executed for objects we have no interest in dumping. That
optimization got broken when the dump flag was turned into a bitmask,
because irrelevant bits tended to remain set in many cases. Since
the "components" field starts from a minimal set of bits and is
added onto as needed, ANDing it with "dump" provides a reliable
indicator of what we actually have to dump, without having to
complicate the logic that manages the request bits. This makes
a significant difference in the number of queries needed when,
for example, there are many functions in extensions.
Discussion: https://postgr.es/m/2273648.1634764485@sss.pgh.pa.us
Discussion: https://postgr.es/m/7d7eb6128f40401d81b3b7a898b6b4de@W2012-02.nidsa.loc
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/5209c0ba0bfd16f23e38f707e487c0626e70564c
Modified Files
--------------
src/bin/pg_dump/common.c | 2 +
src/bin/pg_dump/pg_dump.c | 616 +++++++++++++++++++++++++---------------------
src/bin/pg_dump/pg_dump.h | 13 +-
3 files changed, 351 insertions(+), 280 deletions(-)
