Re: Let's make PostgreSQL multi-threaded
От | Dave Cramer |
---|---|
Тема | Re: Let's make PostgreSQL multi-threaded |
Дата | |
Msg-id | CADK3HH+uWLr-C-iOhPs7LSx9M36wjtpA+x=EGDHiMWvBt_eNXQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Let's make PostgreSQL multi-threaded (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Let's make PostgreSQL multi-threaded
|
Список | pgsql-hackers |
On Fri, 9 Jun 2023 at 18:29, Stephen Frost <sfrost@snowman.net> wrote:
Greetings,
* Dave Cramer (davecramer@postgres.rocks) wrote:
> One thing I can think of is upgrading. AFAIK dump and restore is the only
> way to change the on disk format.
> Presuming that eventually we will be forced to change the on disk format it
> would be nice to be able to do so in a manner which does not force long
> down times
There is an ongoing effort moving in this direction. The $subject isn't
great, but this patch set (which we are currently working on
updating...): https://commitfest.postgresql.org/43/3986/ attempts
changing a lot of currently compile-time block-size pieces to be
run-time which would open up the possibility to have a different page
format for, eg, different tablespaces. Possibly even different block
sizes. We'd certainly welcome discussion from others who are
interested.
Thanks,
Stephen
Upgrading was just one example of difficult problems that need to be addressed.
My thought was that before we commit to something as potentially resource intensive as changing the threading model we compile a list of other "big issues" and prioritize.
I realize open source is more of a scratch your itch kind of development model, but I'm not convinced the random walk that entails is the appropriate way to move forward. At the very least I'd like us to question it.
Dave
В списке pgsql-hackers по дате отправления: