Re: Changing types of block and chunk sizes in memory contexts

> In memory contexts, block and chunk sizes are likely to be limited by
> some upper bounds. Some examples of those bounds can be
> MEMORYCHUNK_MAX_BLOCKOFFSET and MEMORYCHUNK_MAX_VALUE. Both values are
> only 1 less than 1GB.
> This makes memory contexts to have blocks/chunks with sizes less than
> 1GB. Such sizes can be stored in 32-bits. Currently, "Size" type,
> which is 64-bit, is used, but 32-bit integers should be enough to
> store any value less than 1GB.

size_t (= Size) is the correct type in C to store the size of an object
in memory. This is partially a self-documentation issue: If I see
size_t in a function signature, I know what is intended; if I see
uint32, I have to wonder what the intent was.

You could make an argument that using shorter types would save space for
some internal structs, but then you'd have to show some more information
where and why that would be beneficial. (But again, self-documentation:
If one were to do that, I would argue for introducing a custom type like
pg_short_size_t.)

Absent any strong performance argument, I don't see the benefit of this
change. People might well want to experiment with MEMORYCHUNK_...
settings larger than 1GB.