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
|
Список | 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 по дате отправления: