Re: Berserk Autovacuum (let's save next Mandrill)
От | Laurenz Albe |
---|---|
Тема | Re: Berserk Autovacuum (let's save next Mandrill) |
Дата | |
Msg-id | 19be41199e7b303bbecc1066bd9f011d95882aa8.camel@cybertec.at обсуждение исходный текст |
Ответ на | Re: Berserk Autovacuum (let's save next Mandrill) (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Berserk Autovacuum (let's save next Mandrill)
|
Список | pgsql-hackers |
On Mon, 2020-03-16 at 13:13 -0700, Andres Freund wrote: > > Freezing tuples is the point of this patch. > > Sure. But not hurting existing installation is also a goal of the > patch. Since this is introducing potentially significant performance > downsides, I think it's good to be a bit conservative with the default > configuration. > > I'm gettin a bit more bullish on implementing some of what what I > discussed in > https://www.postgresql.org/message-id/20200313213851.ejrk5gptnmp65uoo%40alap3.anarazel.de > at the same time as this patch. > > In particularl, I think it'd make sense to *not* have a lower freezing > horizon for insert vacuums (because it *will* cause problems), but if > the page is dirty anyway, then do the freezing even if freeze_min_age > etc would otherwise prevent us from doing so? I don't quite see why freezing tuples in insert-only tables will cause problems - are you saying that more WAL will be written compared to freezing with a higher freeze_min_age? > > As I have said, if you have a table where you insert many rows in few > > transactions, you would trigger an autovacuum that then ends up doing nothing > > because none of the rows have reached vacuum_freeze_table_age yet. > > Then some time later you will get a really large vacuum run. > > Well, only if you don't further insert into the table. Which isn't that > common a case for a table having a "really large vacuum run". Ah, yes, you are right. So it actually would not be worse if we use the normal freeze_min_age for insert-only vacuums. So do you think the patch would be ok as it is if we change only that? Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления: