Re: PROC_IN_ANALYZE stillborn 13 years ago
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: James Coleman <jtc331@gmail.com>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>, simon@2ndquadrant.com
Date: 2020-08-06T01:07:11Z
Lists: pgsql-hackers
Hi, On 2020-08-05 19:55:49 -0400, Alvaro Herrera wrote: > Back in the 8.3 cycle (2007) when the autovacuum launcher/worker split > was done, we annoyed people because it blocked DDL. That led to an > effort to cancel autovac automatically when that was detected, by Simon > Riggs. > https://postgr.es/m/1191526327.4223.204.camel@ebony.site > https://postgr.es/m/1192129897.4233.433.camel@ebony.site > > I was fixated on only cancelling when it was ANALYZE, to avoid losing > any VACUUM work. > https://postgr.es/m/20071025164150.GF23566@alvh.no-ip.org > That turned into some flags for PGPROC to detect whether a process was > ANALYZE, and cancel only those. > https://postgr.es/m/20071024151328.GG6559@alvh.no-ip.org > Commit: > https://postgr.es/m/20071024205536.CB425754229@cvs.postgresql.org > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=745c1b2c2ab > > However, I was outvoted, so we do not limit cancellation to analyze. > Patch and discussion: https://postgr.es/m/20071025164150.GF23566@alvh.no-ip.org > Commit: > https://postgr.es/m/20071026204510.AA02E754229@cvs.postgresql.org > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=acac68b2bca > > ... which means the flag I had added two days earlier has never been > used for anything. We've carried the flag forward to this day for > almost 13 years, dutifully turning it on and off ... but never checking > it anywhere. > > I propose to remove it, as in the attached patch. I'm mildly against that, because I'd really like to start making use of the flag. Not so much for cancellations, but to avoid the drastic impact analyze has on bloat. In OLTP workloads with big tables, and without disabled cost limiting for analyze (or slow IO), the snapshot that analyze holds is often by far the transaction with the oldest xmin. It's not entirely trivial to fix (just ignoring it could lead to detoasting issues), but also not that. Only mildly against because it'd not be hard to reintroduce once we need it. Greetings, Andres Freund
Commits
-
Call out vacuum considerations in create index docs
- c285a244f6d3 13.2 landed
- 93c39f987e9c 14.0 landed
- 259b21233032 12.6 landed
-
Document concurrent indexes waiting on each other
- ed9c9b033546 11.11 landed
- d3bd36a63d69 10.16 landed
- b3d33bf598dd 9.6.21 landed
- b2603f16ad75 12.6 landed
- 968a537b432e 9.5.25 landed
- 58ebe967f8a1 14.0 landed
- 3fe0e7c3fa27 13.2 landed
-
snapshot scalability: Don't compute global horizons while building snapshots.
- dc7420c2c927 14.0 cited
-
Remove PROC_IN_ANALYZE and derived flags
- cea3d5589865 14.0 landed
-
Improve performance of get_actual_variable_range with recently-dead tuples.
- 3ca930fc39cc 11.0 cited