Re: doing also VM cache snapshot and restore with pg_prewarm, having more information of the VM inside PostgreSQL

Поиск
Список
Период
Сортировка
От Cédric Villemain
Тема Re: doing also VM cache snapshot and restore with pg_prewarm, having more information of the VM inside PostgreSQL
Дата
Msg-id 30ed87d1-f430-48b3-8904-3bb917ac0d90@abcsql.com
обсуждение исходный текст
Ответ на doing also VM cache snapshot and restore with pg_prewarm, having more information of the VM inside PostgreSQL  (Cedric Villemain <Cedric.Villemain+pgsql@abcSQL.com>)
Список pgsql-hackers
Le 04/01/2024 à 23:41, Jim Nasby a écrit :
> On 1/3/24 5:57 PM, Cedric Villemain wrote:
>>
>> for 15 years pgfincore has been sitting quietly and being used in 
>> large setups to help in HA and resources management.
>> It can perfectly stay as is, to be honest I was expecting to one day 
>> include a windows support and propose that to PostgreSQL, it appears 
>> getting support on linux and BSD is more than enough today.
>>
>> So I wonder if there are interest for having virtual memory snapshot 
>> and restore operations with, for example, pg_prewarm/autowarm ?
>>
> IMHO, to improve the user experience here we'd need something that 
> combined the abilities of all these extensions into a cohesive interface 
> that allowed users to simply say "please get this data into cache". 
> Simply moving pgfincore into core Postgres wouldn't satisfy that need.

This is exactly why I proposed those additions to pg_prewarm and autowarm.

> So I think the real question is whether the community feels spport for 
> better cache (buffercache + filesystem) management is a worthwhile 
> feature to add to Postgres.

Agreed, to add in an extension more probably and only the "filesystem" 
part as the buffercache is done already.

> Micromanaging cache contents for periodic jobs seems almost like a 
> mis-feature. While it's a useful tool to have in the toolbox, it's also 
> a non-trivial layer of complexity. IMHO not something we'd want to add. 
> Though, there might be smaller items that would make creating tools to 
> do that easier, such as some ability to see what blocks a backend is 
> accessing (perhaps via a hook).

 From my point of view it's not so complex, but this is subjective and I 
won't argue in this area.

I confirm that having someway to get feedback on current position/block 
activity (and distance/context: heap scan, index build, analyze, ...) 
would be super useful to allow external management. Maybe the "progress" 
facilities can be used for that. Maybe worth looking at that for another 
proposal than the current one.

To be clear I am not proposing that PostgreSQL handles those tasks 
transparently or itself, but offering options to the users via 
extensions like we do with pg_prewarm and pg_buffercache.
It's just the same for virtual memory/filesystem.

---
Cédric Villemain +33 (0)6 20 30 22 52
https://Data-Bene.io
PostgreSQL Expertise, Support, Training, R&D




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

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: Adding facility for injection points (or probe points?) for more advanced tests
Следующее
От: "Hayato Kuroda (Fujitsu)"
Дата:
Сообщение: RE: speed up a logical replica setup