Re: Huge number of disk writes after migration to 8.1

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Huge number of disk writes after migration to 8.1
Дата
Msg-id 24398.1137609367@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Huge number of disk writes after migration to 8.1  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: Huge number of disk writes after migration to 8.1  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-bugs
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Tom Lane wrote:
>> I'm tempted to change pgstat_recv_vacuum
>> and pgstat_recv_analyze so that they will not create new hash entries,
>> but only insert the row count if the hash entry already exists.  I am a
>> bit worried that I might be missing something about possible
>> interactions with autovacuum though.  I see that autovac skips vacuuming
>> tables that have no hash entry ... is there some circular reasoning
>> going on there?

> The idea was that autovac should skip tables for which it doesn't have
> info, because it can't decide and we chose to err on the side of
> caution.  However, after a vacuum or analyze we do have info about the
> table, which is what we store in the pgstat_recv functions
> inconditionally.  Thus the next autovacuum is able to make an informed
> decision about this table.

However, if it skips the table for lack of info, then there still won't
be any info next time.

More to the point, that's not why we skip entry-less tables.  We skip
entry-less tables because there is no need for autovac to do anything to
a table that's not being modified, and if it *is* being modified then
those operations will result in creation of a table entry.  So I'm still
not seeing why vacuum or analyze should force creation of an entry.

            regards, tom lane

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Huge number of disk writes after migration to 8.1
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Huge number of disk writes after migration to 8.1