Re: Add parallelism and glibc dependent only options to reindexdb
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
Julien Rouhaud <rjuju123@gmail.com>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Thomas Munro <thomas.munro@gmail.com>,
Daniel Verite <daniel@manitou-mail.org>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Kevin Grittner <kgrittn@gmail.com>
Date: 2019-07-28T14:07:27Z
Lists: pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes: > Just wondering something... List cells include one pointer, one > signed integer and an OID. The two last entries are basically 4-byte > each, hence could we reduce a bit the bloat by unifying both of them? We couldn't really simplify the API that way; for example, lfirst_int and lfirst_oid *must* be different because they must return different types. I think it'd be a bad idea to have some parts of the API that distinguish the two types while others pretend they're the same, so there's not much room for shortening that. You could imagine unifying the implementations of many of the _int and _oid functions, but I can't get excited about that. It would add confusion for not a lot of code savings. > I understand that the distinction exists because both may not be of > the same size.. Well, even more to the point, one's signed and one isn't. In the long run, might we ever switch to 64-bit OIDs? I dunno. Now that we kicked them out of user tables, it might be feasible, but by the same token there's not much pressure to do it. regards, tom lane
Commits
-
Add support for --jobs in reindexdb
- 5ab892c391c6 13.0 landed
-
Remove more progname references in vacuumdb.c
- 3cae75f4209b 13.0 landed
-
Refactor parallelization processing code in src/bin/scripts/
- 5f3840370b63 13.0 landed