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

From Robert Haas
Subject Re: NAMEDATALEN increase because of non-latin languages
Date
Msg-id CA+TgmoYFj1=ezCyJBho8n=8CwjY+_mLvZiSXfsmgUaqLE65J7g@mail.gmail.com
Whole thread Raw
In response to Re: NAMEDATALEN increase because of non-latin languages  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: NAMEDATALEN increase because of non-latin languages
List pgsql-hackers
On Thu, Jun 23, 2022 at 2:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sounds worth investigating, anyway.  It'd also get us out from under
> C-struct-related problems such as the nearby AIX alignment issue.

Yeah.

> The extra cost of the deforming step could also be repaid, in some
> cases, by not having to use SysCacheGetAttr etc later on to fetch
> variable-length fields.  That is, I'm imagining that the deformer
> would extract all the fields, even varlena ones, and drop pointers
> or whatever into fields of the C struct.

Yeah, if we were going to do something like this, I can't see why we
wouldn't do it this way. It wouldn't make sense to do it for only some
of the attributes.

I'm not sure exactly where we would put this translation step, though.
I think for the syscaches and relcache we'd want to translate when
populating the cache so that when you do a cache lookup you get the
data already translated. It's hard to be sure without testing, but
that seems like it would make this cheap enough that we wouldn't have
to be too worried, since the number of times we build new cache
entries should be small compared to the number of times we access
existing ones. The trickier thing might be code that uses
systable_beginscan() et. al. directly.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: NAMEDATALEN increase because of non-latin languages
Next
From: Heikki Linnakangas
Date:
Subject: Re: Race condition in TransactionIdIsInProgress