Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue)
| От | Justin Pryzby |
|---|---|
| Тема | Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue) |
| Дата | |
| Msg-id | 20221229012354.GF1153@telsasoft.com обсуждение исходный текст |
| Ответ на | Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue)
|
| Список | pgsql-hackers |
On Wed, Dec 28, 2022 at 03:13:23PM -0500, Tom Lane wrote:
> Peter Geoghegan <pg@bowt.ie> writes:
> > On Fri, Dec 16, 2022 at 6:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> That is a really good point. How about teaching VACUUM to track
> >> the oldest original relfrozenxid and relminmxid among the table(s)
> >> it processed, and skip vac_update_datfrozenxid unless at least one
> >> of those matches the database's values? For extra credit, also
> >> skip if we didn't successfully advance the source rel's value.
>
> > Hmm. I think that that would probably work.
>
> I'm forced to the conclusion that we have to expose some VACUUM
> options if we want this to work well. Attached is a draft patch
> that invents SKIP_DATABASE_STATS and ONLY_DATABASE_STATS options
> (name bikeshedding welcome) and teaches vacuumdb to use them.
I was surprised to hear that this added *two* options.
I assumed it would look like:
VACUUM (UPDATE_DATABASE_STATS {yes,no,only})
--
Justin
В списке pgsql-hackers по дате отправления: