Re: Turning off HOT/Cleanup sometimes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Turning off HOT/Cleanup sometimes
Дата
Msg-id 18329.1389303834@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Turning off HOT/Cleanup sometimes  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Turning off HOT/Cleanup sometimes  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> The problem with saying that we should let VACUUM do this work is the
> same as the problem with saying that if you're late for your Concorde
> flight, you should go running across the tarmac and try to catch it.
> The cost of dead tuples is related in a linear fashion to the rate at
> which pages are accessed.  Not coincidentally, the number of
> opportunities for HOT pruning is *also* related in a linear fashion to
> the rate at which pages are accessed.  This is why it works so well.

That seems like a large oversimplification.  Some (most?) of the costs of
dead tuples are proportional to the rate of dead tuple creation.  I grant
that there are also some costs proportional to the rate at which scans
visit dead tuples, but I really don't believe that the latter are
dominant.  So I think it's bogus to claim that the current behavior is
somehow optimal.

One more time: the sole reason it works the way it does now is that that
was the path of least resistance back in 2007, and we never yet got around
to trying to optimize that.  I'm glad to see someone wanting to revisit
the issue, but I don't think that we necessarily have to go as far as
creating user-visible knobs in order to make it better.

> The rate at which vacuuming happens does not ramp up in the same way;
> it's limited by autovacuum cost settings (which people tend not have
> set correctly, and don't adjust themselves on the fly)

True, but that seems like a pretty well-defined improvement project right
there (as well as an argument against user-visible knobs in general ;-)).
Nasby's speculations just upthread could be useful here, too.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Steeve Lennmark
Дата:
Сообщение: Re: [PATCH] Relocation of tablespaces in pg_basebackup
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: nested hstore patch