From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Subject: | Re: New IndexAM API controlling index vacuum strategies |
Date: | 2021-04-06 00:00:31 |
Message-ID: | 20210406000031.j2wzn6ipaebkad74@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2021-04-05 16:53:58 -0700, Peter Geoghegan wrote:
> REL_13_STABLE will need to be considered separately. I still haven't
> figured out how this ever appeared to work for this long. The
> vac_strategy/bstrategy state simply wasn't propagated at all.
What do you mean with "appear to work"? Isn't, in 13, the only
consequence of vac_strategy not being "propagated" that we'll not use a
strategy in parallel workers? Presumably that was hard to notice
because most people don't run manual VACUUM with cost limits turned
on. And autovacuum doesn't use parallelism.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2021-04-06 00:09:02 | Re: New IndexAM API controlling index vacuum strategies |
Previous Message | Peter Geoghegan | 2021-04-05 23:53:58 | Re: New IndexAM API controlling index vacuum strategies |