Re: [HACKERS] Slow count(*) again...

Поиск
Список
Период
Сортировка
От Joshua D. Drake
Тема Re: [HACKERS] Slow count(*) again...
Дата
Msg-id 1296786810.18411.102.camel@jd-desktop
обсуждение исходный текст
Ответ на Re: [HACKERS] Slow count(*) again...  (Conor Walsh <ctw@adverb.ly>)
Ответы Re: [HACKERS] Slow count(*) again...  (Conor Walsh <ctw@adverb.ly>)
Список pgsql-performance
On Thu, 2011-02-03 at 18:12 -0800, Conor Walsh wrote:
> > I can't remember
> > anyone ever complaining "ANALYZE took too long to run".  I only
> > remember complaints of the form "I had to remember to manually run it
> > and I wish it had just happened by itself".
>
> Robert,
>
> This sounds like an argument in favor of an implicit ANALYZE after all
> COPY statements, and/or an implicit autoanalyze check after all
> INSERT/UPDATE statements.

Well that already happens. Assuming you insert/update or copy in a
greater amount than the threshold for the

autovacuum_analyze_scale_factor

Then autovacuum is going to analyze on the next run. The default is .1
so it certainly doesn't take much.

JD

>
> -Conor
>

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt


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

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