Re: collations in shared catalogs?

Поиск
Список
Период
Сортировка
От David Steele
Тема Re: collations in shared catalogs?
Дата
Msg-id 54F72860.70508@pgmasters.net
обсуждение исходный текст
Ответ на Re: collations in shared catalogs?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Hi Robert,

On 3/4/15 10:14 AM, Robert Haas wrote:
> On Wed, Feb 25, 2015 at 7:54 PM, David Steele <david@pgmasters.net> wrote:
>> +1 on 128/256 character names.
>>
>>> /me runs and hides.
>>
>> /stands brazenly in the open and volunteers to try it if I don't get
>> clobbered within seconds.
>
> I think the question is whether making lots of rows in system catalogs
> better is going to have undesirable effects on (a) the size of our
> initial on-disk format (i.e. how big an empty database is), (b) the
> amount of memory consumed by the syscache and relcaches on workloads
> that touch lots of tables/functions/whatever, or (c) CPU consumption
> mostly as a result of more cache line accesses for the same operation.
> If you can prove those effects are minimal, that'd be a good place to
> start.

Thanks, that's encouraging.  I've already compiled with NAMEDATALEN=256
and verified that the only failing tests are the ones making sure that
identifier lengths are truncated or fail appropriately when they are >
63.  I'm sure lots of people have done that before and gotten the same
result.

I'm currently investigating the issues that you've identified above
since they constitute the real problem with increasing NAMEDATALEN.
Once I have some answers I'll send a proposal to hackers.

--
- David Steele
david@pgmasters.net


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Weirdly pesimistic estimates in optimizer
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Strange assertion using VACOPT_FREEZE in vacuum.c