Re: plpgsql function startup-time improvements

"Tels" <nospam-pg-abuse(at)bloodgate(dot)com> writes:
> On Thu, December 28, 2017 5:43 pm, Tom Lane wrote:
>> Which field order were you checking? Are you accounting for alignment
>> padding?
> ...
> Sounds logical, thanx for the detailed explanation. In my test the first 4
> padding bytes are probably not there, because I probably miss something
> that aligns ptrs on 8-byte boundaries. At least that would explain the
> sizes seen here.

Hm, yeah, you would get different results on a compiler that considered
pointers to only require 4-byte alignment. Although that would be an
ABI break, so I'm surprised to hear there are any x86_64 compilers that
do that by default.

> So, if you moved "isnull" and "freeval" right behind "isconst" and
> "notnull", you could save another 2 byte, land at 64, and thus no extra
> padding would keep it at 64?

I thought about that idea while reading your earlier message,
but I don't favor it for two reasons:

* It'd be an illogical ordering of the fields: isnull and freeval
belong with the value, not somewhere else. This is not simply an
academic point, because of the field-sharing conventions represented
by PLpgSQL_variable. I expect that sometime soon we will get
around to implementing CONSTANT, NOT NULL, and initializer properties
for composite variables, and the most natural way to do that will be
to include the isconst, notnull, and default_val fields into
PLpgSQL_variable so they can be shared by PLpgSQL_var and PLpgSQL_rec.
Shoving isnull and freeval into the middle of that would be really ugly.

* The second patch I posted in this thread adds another enum field
at the end of PLpgSQL_var. Right now, with either field ordering
under discussion, that's basically free space-wise because it's
just going into what would otherwise be trailing padding space.
But it destroys any space savings from moving isnull and freeval
somewhere else.

In the end, it's not wise to put too much emphasis on struct size
and padding considerations, as that just ends up being platform
dependent anyway. None of what we've said in this back-and-forth
is quite right for 32-bit-pointer machines, and once Peter's stdbool
patch lands, the assumption that bool is 1 byte will be shaky as
well. I think actually the point about maintaining a logical field
order is the most significant consideration here. There's no great
harm in trying to avoid space wastage on today's most popular
machines, but we shouldn't let that consideration contort the code
very far.

regards, tom lane