From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | Денис Романенко <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: | 2021-08-18 12:04:06 |
Message-ID: | CAFBsxsHLT4qo-XQb1c-rjJbVJMd-VRXDJHEnFLyhTN1DX8=wVg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 18, 2021 at 7:33 AM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> > Some actual numbers on recent hardware would show what kind of tradeoff
is involved. No one has done that for a long time that I recall.
>
> Agreed, but I don't have access to such hardware. However this won't
Well, by "recent" I had in mind something more recent than 2002, which is
the time where I see a lot of hits in the archives if you search for this
topic.
> influence the memory overhead part, and there is already frequent
> problems with that, especially since declarative partitioning, so I
That's a fair point.
> don't see how we could afford that without some kind of cache TTL or
> similar. AFAIR the last discussion about it a few years ago didn't
> lead anywhere :(
If you mean the thread "Protect syscache from bloating with negative cache
entries", it had activity earlier this year, so I wouldn't give up hope
just yet. Progress has been slow, so I'll see about putting some effort
into that after concluding my attempt to speed up the syscaches first [1].
The main thing I'm worried about is the fact that a name would no longer
fit in a Datum. The rest I think we can mitigate in some way.
--
John Naylor
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2021-08-18 12:07:23 | Re: NAMEDATALEN increase because of non-latin languages |
Previous Message | Hannu Krosing | 2021-08-18 12:03:21 | Re: NAMEDATALEN increase because of non-latin languages |