Re: Potential autovacuum optimization: new tables

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Potential autovacuum optimization: new tables
Дата
Msg-id 20121013021339.GE29165@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Potential autovacuum optimization: new tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Potential autovacuum optimization: new tables
Re: Potential autovacuum optimization: new tables
Список pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> [ shrug... ]  You're attacking a straw man, or more precisely putting
> words into my mouth about what the percentage-based thresholds might be.
> Notice the examples I gave involved update percentages quite far north
> of 100%.  It's possible and maybe likely that we need a sliding scale.

I was just discussing such a sliding scale approach w/ Josh on IRC, my
thinking was that we could use a logarithmic approach based on table
size.

> Also, I don't necessarily accept the conclusion you seem to be drawing,
> that it's okay to have complete turnover of a small table and not redo
> its stats.  If you don't like the current behavior when there's no
> stats, why would you like the behavior when there are some stats but
> they no longer have the remotest relationship to reality?

Josh's concern is about autovacuum causing lots of stats churn, which is
understandable, we don't want it constantly rescanning a table, but
perhaps we could use some kind of threshold for preventing autovac from
rescanning a table it just scanned?  Note that I did *not* say 'GUC',
but I don't know what the 'right' answer is for how frequently is
good-but-not-too-frequent.  I'd also like to try and avoid adding GUCs.
Thanks,
    Stephen

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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Potential autovacuum optimization: new tables
Следующее
От: David Johnston
Дата:
Сообщение: Re: Potential autovacuum optimization: new tables