Re: NAMEDATALEN increase because of non-latin languages

From: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Денис Романенко <deromanenko(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: NAMEDATALEN increase because of non-latin languages
Date: 2022-06-03 06:28:16
Message-ID: CAFBsxsF2V8n9w0SGK56bre3Mk9fzZS=9aaA8Gfs_n+woa3Dr-Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I wanted to revive this thread to summarize what was discussed and get
a sense of next steps we could take.

The idea that gained the most traction is to make identifiers
variable-length in the catalogs, which has the added benefit of
reducing memory in syscaches in the common case. That presented two
challenges:

1. That would require putting the name physically closer to the end of
the column list. To make this less annoying for users, we'd need to
separate physical order from display order (at least/at first only for
system catalogs). This would require:

- changing star expansion in SELECTs (expandRTE etc)
- adjusting pg_dump, \d, etc

That much seems clear and agreed upon.

2. We'd need to change how TupleDescs are stored and accessed.

For this point, Matthias shared a prototype patch for a 'compact
attribute access descriptor' and Andres wondered if we should "give up
on the struct / ondisk layout mirroring for catalog tables, and
generate explicit transformation routines via Catalog.pm".

After this discussion dropped off, and it's not quite clear to me what
the first logical step is to make progress on the thread subject, and
what's nice to have for other reasons. Is Matthias's patch or
something like it a good next step?

--
John Naylor
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thibaud W. 2022-06-03 08:12:30 Re: Proposal: adding a better description in psql command about large objects
Previous Message Masahiko Sawada 2022-06-03 05:39:52 Re: Add index scan progress to pg_stat_progress_vacuum