Re: making relfilenodes 56 bits

Поиск
Список
Период
Сортировка
От Matthias van de Meent
Тема Re: making relfilenodes 56 bits
Дата
Msg-id CAEze2WjtWvG1BFDnhW94DA3DOHeu8P2hqcF0g5ZMcY+HtcOt1w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: making relfilenodes 56 bits  (Simon Riggs <simon.riggs@enterprisedb.com>)
Ответы Re: making relfilenodes 56 bits  (Simon Riggs <simon.riggs@enterprisedb.com>)
Список pgsql-hackers
On Tue, 28 Jun 2022 at 13:45, Simon Riggs <simon.riggs@enterprisedb.com> wrote:
> but since the number of combinations is usually 1, but even then, low,
> it can be cached easily in a smgr array and included in the checkpoint
> record (or nearby) for ease of use.

I was reading the thread to keep up with storage-related prototypes
and patches, and this specifically doesn't sound quite right to me. I
do not know what values you considered to be 'low' or what 'can be
cached easily', so here's some field data:

I have seen PostgreSQL clusters that utilized the relative isolation
of seperate databases within the same cluster (instance / postmaster)
to provide higher guarantees of data access isolation while still
being able to share a resource pool, which resulted in several
clusters containing upwards of 100 databases.

I will be the first to admit that it is quite unlikely to be common
practise, but this workload increases the number of dbOid+spcOid
combinations to 100s (even while using only a single tablespace),
which in my opinion requires some more thought than just handwaving it
into an smgr array and/or checkpoint records.


Kind regards,

Matthias van de Meent



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: margay fails assertion in stats/dsa/dsm code
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Separate the attribute physical order from logical order