Re: Add parallelism and glibc dependent only options to reindexdb - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Add parallelism and glibc dependent only options to reindexdb
Date
Msg-id 25197.1564322847@sss.pgh.pa.us
Whole thread Raw
In response to Re: Add parallelism and glibc dependent only options to reindexdb  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Add parallelism and glibc dependent only options to reindexdb  (Andres Freund <andres@anarazel.de>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: LLVM compile failing in seawasp
Next
From: Tom Lane
Date:
Subject: Re: Testing LISTEN/NOTIFY more effectively