Re: [HACKERS] Block level parallel vacuum
От | Sergei Kornilov |
---|---|
Тема | Re: [HACKERS] Block level parallel vacuum |
Дата | |
Msg-id | 2441851575221513@iva7-56e9317134d0.qloud-c.yandex.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Block level parallel vacuum (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Block level parallel vacuum
Re: [HACKERS] Block level parallel vacuum Re: [HACKERS] Block level parallel vacuum |
Список | pgsql-hackers |
Hi > I think I got your point. Your proposal is that it's more efficient if > we make the leader process vacuum the index that can be processed only > the leader process (i.e. indexes not supporting parallel index vacuum) > while workers are processing indexes supporting parallel index vacuum, > right? That way, we can process indexes in parallel as much as > possible. Right > So maybe we can call vacuum_or_cleanup_skipped_indexes first > and then call vacuum_or_cleanup_indexes_worker. But I'm not sure that > there are parallel-safe remaining indexes after the leader finished > vacuum_or_cleanup_indexes_worker, as described on your proposal. I meant that after processing missing indexes (not supporting parallel index vacuum), the leader can start processing indexesthat support the parallel index vacuum, along with parallel workers. Exactly call vacuum_or_cleanup_skipped_indexes after start parallel workers but before vacuum_or_cleanup_indexes_worker orsomething with similar effect. If we have 0 missed indexes - parallel vacuum will run as in current implementation, with leader participation. Sorry for my unclear english... regards, Sergei
В списке pgsql-hackers по дате отправления: