From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Kevin Grittner <kgrittn(at)gmail(dot)com> |
Subject: | Re: Add parallelism and glibc dependent only options to reindexdb |
Date: | 2019-07-28 14:07:27 |
Message-ID: | 25197.1564322847@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-07-28 16:07:41 | Re: Testing LISTEN/NOTIFY more effectively |
Previous Message | Tom Lane | 2019-07-28 13:54:05 | Re: LLVM compile failing in seawasp |