Re: Potential autovacuum optimization: new tables - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Potential autovacuum optimization: new tables
Date
Msg-id 507C460B.8020708@agliodbs.com
Whole thread Raw
In response to Re: Potential autovacuum optimization: new tables  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert,

> As I've said before (and I believe Simon has said similar things), I
> think we should be vacuuming the heap much more often but only doing
> index vac when we accumulate enough dead tuples to justify the cost of
> the index scan.  Pruning the heap is cheap and very effective.

You are probably correct, especially since the testing which set the
current thresholds was pre-HOT, even.

We don't have a vacuum method which allows us to vacuum the heap but not
the indexes, though, do we?

Note that the only time I encounter chronic autovacuum issues, it's for
"problem" tables like queue tables, and no default is going to cope with
those.

Anyway, big thing is, we need to be able to test this.

> That's a pretty funny-looking curve, because it doubles between 10 and
> 100 but then increases 10x between 100 and 1000.  It's similarly
> erratic further on.  But I do agree that some kind of log scale might
> be appropriate.

Yeah, it's mainly the endpoints I'm sure of based on experience.  The
middle should be a smooth curve between them, if possible.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Truncate if exists
Next
From: Simon Riggs
Date:
Subject: Re: Deprecating Hash Indexes