Re: PROC_IN_ANALYZE stillborn 13 years ago - Mailing list pgsql-hackers

From Andres Freund
Subject Re: PROC_IN_ANALYZE stillborn 13 years ago
Date
Msg-id 20200806010711.mzvu36zy25xer33t@alap3.anarazel.de
Whole thread Raw
In response to PROC_IN_ANALYZE stillborn 13 years ago  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: PROC_IN_ANALYZE stillborn 13 years ago
Re: PROC_IN_ANALYZE stillborn 13 years ago
Re: PROC_IN_ANALYZE stillborn 13 years ago
List 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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Reg. Postgres 13
Next
From: "k.jamison@fujitsu.com"
Date:
Subject: RE: [Patch] Optimize dropping of relation buffers using dlist