Re: NAMEDATALEN increase because of non-latin languages - Mailing list pgsql-hackers

From Andres Freund
Subject Re: NAMEDATALEN increase because of non-latin languages
Date
Msg-id 20220719155719.mz2p6gpaab32u2nd@awork3.anarazel.de
Whole thread Raw
In response to Re: NAMEDATALEN increase because of non-latin languages  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: NAMEDATALEN increase because of non-latin languages
List pgsql-hackers
Hi,

On 2022-07-19 14:30:34 +0700, John Naylor wrote:
> I wrote:
> 
> > On Mon, Jul 18, 2022 at 9:58 AM Andres Freund <andres@anarazel.de> wrote:
> > > Hm. Wouldn't it make sense to just use the normal tuple deforming
> routines and
> > > then map the results to the structs?
> >
> > I wasn't sure if they'd be suitable for this, but if they are, that'd
> make this easier and more maintainable. I'll look into it.
> 
> This would seem to have its own problems: heap_deform_tuple writes to
> passed arrays of datums and bools. The lower level parts like fetchatt and
> nocachegetattr return datums, so still need some generated boilerplate.
> Some of these also assume they can write cached offsets on a passed tuple
> descriptor.

Sure. But that'll just be a form of conversion we do all over, rather than
encoding low-level data layout details. Basically
struct->member1 = DatumGetInt32(values[0]);
struct->member2 = DatumGetChar(values[1]);

etc.


> I'm thinking where the first few attributes are fixed length, not null, and
> (because of AIX) not double-aligned, we can do a single memcpy on multiple
> columns at once. That will still be a common pattern after namedata is
> varlen. Otherwise, use helper functions/macros similar to the above but
> instead of passing a tuple descriptor, use info we have at compile time.

I think that might be over-optimizing things. I don't think we do these
conversions at a rate that's high enough to warrant it - the common stuff
should be in relcache etc.  It's possible that we might want to optimize the
catcache case specifically - but that'd be more optimizing memory usage than
"conversion" imo.


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Convert planner's AggInfo and AggTransInfo to Nodes
Next
From: Jacob Champion
Date:
Subject: Re: [PATCH] Log details for client certificate failures