Hi, On 2020-03-16 20:49:43 +0100, Laurenz Albe wrote: > On Mon, 2020-03-16 at 07:47 -0500, Justin Pryzby wrote: > > It seems to me that the easy thing to do is to implement this initially > > without > > FREEZE (which is controlled by vacuum_freeze_table_age), and defer until > > July/v14 further discussion and implementation of another GUC/relopt for > > autovacuum freezing to be controlled by insert thresholds (or ratio). > > 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? It'd probably be ok to incur the WAL logging overhead unconditionally, but I'm not sure about it. > 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". Greetings, Andres Freund
