| From: | Daniil Davydov <3danissimo(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, Maxim Orlov <orlovmg(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: POC: Parallel processing of indexes in autovacuum |
| Date: | 2026-04-01 21:43:47 |
| Message-ID: | CAJDiXgij4jrmVUF07wOF_ODZWwREO6dV-PFmUJ06D3_TTXeJJA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Thu, Apr 2, 2026 at 1:55 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> Overall, the results show no noticeable overhead from the polling approach.
Great news! Thank you for these measurements!
BTW, I caught myself thinking that Tom Lane and maybe some other people might
not like our parameter propagation logic. We are not building any new
capability, but supplying an utilitarian solution for a single feature.
Perhaps someone will not consider this a good way to develop new features.
However, I don't think that this is something bad. We have a pretty simple
logic which does not interfere with some other infrastructure. On the other
hand, maybe I am thinking in terms of bigtech product development, where
results (but not the design) are often the most important thing.
--
Best regards,
Daniil Davydov
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2026-04-01 21:52:12 | Re: Adding REPACK [concurrently] |
| Previous Message | Nathan Bossart | 2026-04-01 21:28:45 | Re: Add pg_stat_autovacuum_priority |