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...
|
Список | 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 по дате отправления: