| From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
|---|---|
| To: | Conor Walsh <ctw(at)adverb(dot)ly> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Slow count(*) again... |
| Date: | 2011-02-04 02:33:30 |
| Message-ID: | 1296786810.18411.102.camel@jd-desktop |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2011-02-04 02:37:54 | Re: keeping a timestamp of the last stats reset (for a db, table and function) |
| Previous Message | Andrew Dunstan | 2011-02-04 02:32:31 | Re: exposing COPY API |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Conor Walsh | 2011-02-04 02:45:09 | Re: [HACKERS] Slow count(*) again... |
| Previous Message | Conor Walsh | 2011-02-04 02:12:57 | Re: [HACKERS] Slow count(*) again... |