Re: Potential autovacuum optimization: new tables

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Potential autovacuum optimization: new tables
Дата
Msg-id 507C460B.8020708@agliodbs.com
обсуждение исходный текст
Ответ на Re: Potential autovacuum optimization: new tables  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Truncate if exists
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Deprecating Hash Indexes