Does auto-analyze work on dirty writes? (was: Re: [HACKERS] Slow count(*) again...)

Поиск
Список
Период
Сортировка
От Mark Mielke
Тема Does auto-analyze work on dirty writes? (was: Re: [HACKERS] Slow count(*) again...)
Дата
Msg-id 4D4B7317.3070803@mark.mielke.cc
обсуждение исходный текст
Ответ на Re: [HACKERS] Slow count(*) again...  (Conor Walsh <ctw@adverb.ly>)
Ответы Re: Does auto-analyze work on dirty writes? (was: Re: [HACKERS] Slow count(*) again...)
Список pgsql-performance
On 02/03/2011 09:45 PM, Conor Walsh wrote:
> My understanding is that auto-analyze will fire only after my
> transaction is completed, because it is a seperate daemon.  If I do
> like so:
>
> BEGIN;
> COPY ...;
> -- Dangerously un-analyzed
> SELECT complicated-stuff ...;
> END;
>
> Auto-analyze does not benefit me, or might not because it won't fire
> often enough.  I agree that analyze is very fast, and it often seems
> to me like the cost/benefit ratio suggests making auto-analyze even
> more aggressive.

The count discussion is boring. Nothing new there. But auto-analyze on
dirty writes does interest me. :-)

My understanding is:

1) Background daemon wakes up and checks whether a number of changes
have happened to the database, irrelevant of transaction boundaries.

2) Background daemon analyzes a percentage of rows in the database for
statistical data, irrelevant of row visibility.

3) Analyze is important for both visible rows and invisible rows, as
plan execution is impacted by invisible rows. As long as they are part
of the table, they may impact the queries performed against the table.

4) It doesn't matter if the invisible rows are invisible because they
are not yet committed, or because they are not yet vacuumed.

Would somebody in the know please confirm the above understanding for my
own piece of mind?

Thanks,
mark

--
Mark Mielke<mark@mielke.cc>


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

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: [HACKERS] Slow count(*) again...
Следующее
От: Scott Marlowe
Дата:
Сообщение: Re: [HACKERS] Slow count(*) again...