pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Joshua D. Drake <jd@commandprompt.com>
To: Conor Walsh <ctw@adverb.ly>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: [HACKERS] Slow count(*) again...
Date: Thu, 03 Feb 2011 18:33:30 -0800
Message-ID: <1296786810.18411.102.camel@jd-desktop> (raw)
In-Reply-To: <AANLkTi=XUprgXqV84iY1sukC_6Pos+DfVPFveaK1CSHf@mail.gmail.com>
References: <201102012247.p11Ml6u02682@momjian.us>
	<4D48914B.4050403@dunslane.net>
	<4D489AD1.1010105@vmsinfo.com>
	<AANLkTiknZi97dDwm7sHqy0EL7tpNEP9sY5uPV6AN+q=u@mail.gmail.com>
	<4D499E55.4020107@vmsinfo.com>
	<AANLkTimo2J-BagObs_V1bGaHOO9qL+kTF6s6-wZ=M3KW@mail.gmail.com>
	<AANLkTin7A_Q=Yc9Wf_5=POp2mVqmaiwqUDsFMLG68H45@mail.gmail.com>
	<4D4A7B69.2020704@gmail.com>
	<alpine.DEB.2.00.1102030208440.8162@asgard.lang.hm>
	<AANLkTi=Thet0VZ-X6b7tek+iSLVkE27JjiKrB5D8U0Jd@mail.gmail.com>
	<alpine.DEB.2.00.1102031243190.10088@asgard.lang.hm>
	<AANLkTikmChsPODbUD4V-gQ8k2yYvvjJY6b9K_29+k7nu@mail.gmail.com>
	<alpine.DEB.2.00.1102031637480.30983@asgard.lang.hm>
	<AANLkTi=Kx6rRFs3Kz2m32nLKwLGv0Ee87UF8ngKhppgM@mail.gmail.com>
	<alpine.DEB.2.00.1102031732470.30983@asgard.lang.hm>
	<AANLkTikN14hsVVVLJ=BQdqEcpmzkLLqSbEpqx-th4Ohx@mail.gmail.com>
	<AANLkTi=XUprgXqV84iY1sukC_6Pos+DfVPFveaK1CSHf@mail.gmail.com>

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




view thread (246+ messages)  latest in thread

Message-ID: <1296786810.18411.102.camel@jd-desktop>
Permalink:  ../1296786810.18411.102.camel@jd-desktop/
Also on:    postgresql.org/message-id/1296786810.18411.102.camel@jd-desktop

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: jd@commandprompt.com, ctw@adverb.ly, robertmhaas@gmail.com
  Subject: Re: [HACKERS] Slow count(*) again...
  In-Reply-To: <1296786810.18411.102.camel@jd-desktop>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox