| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Kirill Reshke <reshke(at)double(dot)cloud> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Extensible storage manager API - smgr hooks |
| Date: | 2022-08-26 05:25:58 |
| Message-ID: | D365F19F-BC3E-4F96-A91E-8DB13049749E@yandex-team.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 16 Jun 2022, at 13:41, Kirill Reshke <reshke(at)double(dot)cloud> wrote:
>
> Hello Yura and Anastasia.
FWIW this technology is now a part of Greenplum [0]. We are building GP extension that automatically offloads cold data to S3 - a very simplified version of Neon for analytical workloads.
When a segment of a table is not used for a long period of time, extension will sync files with backup storage in the Cloud.
When the user touches data, extension's smgr will bring table segments back from backup or latest synced version.
Our #1 goal is to provide a tool useful for the community. We easily can provide same extension for Postgres if this technology (extensible smgr) is in core. Does such an extension seem useful for Postgres? Or does this data access pattern seems unusual for Postgres? By pattern I mean vast amounts of cold data only ever appended and never touched.
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | torikoshia | 2022-08-26 05:28:26 | Re: Fix japanese translation of log messages |
| Previous Message | David Rowley | 2022-08-26 05:16:38 | Re: Reducing the chunk header sizes on all memory context types |