Re: [HACKERS] More stats about skipped vacuums - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: [HACKERS] More stats about skipped vacuums
Date
Msg-id CABUevEy_KMR4Gez6FEVCFp41-5mehd_wbC+EnAzYWqWZY_eefA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] More stats about skipped vacuums  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Nov 28, 2017 at 12:16 AM, Tom Lane wrote: > Magnus Hagander writes: > > What I've been thinking about for that one before is if we could just > > invent a protocol (shmq based maybe) whereby autovacuum can ask the stats > > collector for a single table or index stat. If autovacuum never needs to > > see a consistent view between multiple tables, I would think that's going > > to be a win in a lot of cases. > > Perhaps. Autovac might run through quite a few tables before it finds > one in need of processing, though, so I'm not quite certain this would > yield such great benefits in isolation. > Hmm. Good point. > > However, when it comes to the stats system, I'd say that on any busy > system > > (which would be the ones to care about), the stats structures are still > > going to be *written* a lot more than they are read. > > Uh, what? The stats collector doesn't write those files at all except > on-demand. > Oops. Missing one important word. They're going to be *written to* a lot more than they are read. Meaning that each individual value is likely to be updated many times before it's ever read. In memory, in the stats collector. So not talking about the files at all -- just the numbers, independent of implementation. -- Magnus HaganderMe: https://www.hagander.net/ Work: https://www.redpill-linpro.com/

pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: Transform for pl/perl
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] Small improvement to compactify_tuples