Re: NAMEDATALEN increase because of non-latin languages

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: NAMEDATALEN increase because of non-latin languages
Дата
Msg-id CA+TgmoYFj1=ezCyJBho8n=8CwjY+_mLvZiSXfsmgUaqLE65J7g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: NAMEDATALEN increase because of non-latin languages  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: NAMEDATALEN increase because of non-latin languages  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: NAMEDATALEN increase because of non-latin languages
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Race condition in TransactionIdIsInProgress