Re: Potential autovacuum optimization: new tables

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Potential autovacuum optimization: new tables
Date: 2012-10-15 17:21:15
Message-ID: 507C460B.8020708@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-10-15 17:26:43 Re: Deprecating Hash Indexes
Previous Message Robert Haas 2012-10-15 17:20:38 Re: Truncate if exists