Re: Experimenting with hash tables inside pg_dump
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2021-10-22T15:54:13Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2021-10-22 10:53:31 -0400, Tom Lane wrote: >> I'm skeptical of that, mainly because it doesn't work in old servers, > I think we can address that, if we think it's overall a promising approach to > pursue. E.g. if we don't need the indexes, we can make it = ANY(). Hmm ... yeah, I guess we could get away with that. It might not scale as nicely to a huge database, but probably dumping a huge database from an ancient server isn't all that interesting. I'm inclined to think that it could be sane to make getTableAttrs and getIndexes use this style, but we probably still want functions and such to use per-object queries. In those other catalogs there are many built-in objects that we don't really care about. The prepared-queries hack I was working on last night is probably plenty good enough there, and it's a much less invasive patch. Were you planning to pursue this further, or did you want me to? I'd want to layer it on top of the work I did at [1], else there's going to be lots of merge conflicts. regards, tom lane [1] https://www.postgresql.org/message-id/2273648.1634764485%40sss.pgh.pa.us
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