pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Justin Pryzby <pryzby@telsasoft.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: postgresql@taljaren.se, pgsql-bugs@lists.postgresql.org, Peter Geoghegan <pg@bowt.ie>
Subject: Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue)
Date: Wed, 28 Dec 2022 19:29:10 -0600
Message-ID: <20221229012910.GG1153@telsasoft.com> (raw)
In-Reply-To: <Y555O1zrtHOshuRC@paquier.xyz>
References: <17717-6c50eb1c7d23a886@postgresql.org>
	<3439037.1671130590@sss.pgh.pa.us>
	<Y555O1zrtHOshuRC@paquier.xyz>

On Sun, Dec 18, 2022 at 11:21:47AM +0900, Michael Paquier wrote:
> On Thu, Dec 15, 2022 at 01:56:30PM -0500, Tom Lane wrote:
> > * To fix vacuumdb properly, it might be enough to get it to
> > batch VACUUMs, say by naming up to 1000 tables per command
> > instead of just one.  I'm not sure how that would interact
> > with its parallelization logic, though.  It's not really
> > solving the O(N^2) issue either, just pushing it further out.
> 
> I have been thinking about this part, and using a hardcoded rule for
> the batches would be tricky.  The list of relations returned by the
> scan of pg_class are ordered by relpages, so depending on the
> distribution of the sizes (few tables with a large size and a lot of
> table with small sizes, exponential distribution of table sizes), we
> may finish with more downsides than upsides in some cases, even if we
> use a linear rule based on the number of relations, or even if we
> distribute the relations across the slots in a round robin fashion for
> example.

I've always found it weird that it uses "ORDER BY relpages".

I'd prefer if it could ORDER BY age(relfrozenxid) or
GREATEST(age(relfrozenxid), age(relminmxid)), at least if you specify
one of the --min-*age parms.  Or something less hardcoded and
unconfigurable.

-- 
Justin





view thread (29+ messages)  latest in thread

Message-ID: <20221229012910.GG1153@telsasoft.com>
Permalink:  ../20221229012910.GG1153@telsasoft.com/
Also on:    postgresql.org/message-id/20221229012910.GG1153@telsasoft.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: pryzby@telsasoft.com, michael@paquier.xyz, tgl@sss.pgh.pa.us, pg@bowt.ie
  Subject: Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue)
  In-Reply-To: <20221229012910.GG1153@telsasoft.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox