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

help / color / mirror / Atom feed
From: Vitalii Tymchyshyn <tivv00@gmail.com>
To: Kenneth Marshall <ktm@rice.edu>
Cc: david@lang.hm, Robert Haas <robertmhaas@gmail.com>
Cc: Jon Nelson <jnelson+pgsql@jamponi.net>
Cc: Mladen Gogala <mladen.gogala@vmsinfo.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Craig Ringer <craig@postnewspapers.com.au>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: [HACKERS] Slow count(*) again...
Date: Fri, 04 Feb 2011 16:38:30 +0200
Message-ID: <4D4C0F66.1080507@gmail.com> (raw)
In-Reply-To: <20110204143315.GA1261@aart.is.rice.edu>
References: <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>
	<20110204143315.GA1261@aart.is.rice.edu>

04.02.11 16:33, Kenneth Marshall написав(ла):
>
> In addition, the streaming ANALYZE can provide better statistics at
> any time during the load and it will be complete immediately. As far
> as passing the entire table through the ANALYZE process, a simple
> counter can be used to only send the required samples based on the
> statistics target. Where this would seem to help the most is in
> temporary tables which currently do not work with autovacuum but it
> would streamline their use for more complicated queries that need
> an analyze to perform well.
>
Actually for me the main "con" with streaming analyze is that it adds 
significant CPU burden to already not too fast load process. Especially 
if it's automatically done for any load operation performed (and I can't 
see how it can be enabled on some threshold).
And you can't start after some threshold of data passed by since you may 
loose significant information (like minimal values).

Best regards, Vitalii Tymchyshyn



view thread (246+ messages)  latest in thread

Message-ID: <4D4C0F66.1080507@gmail.com>
Permalink:  ../4D4C0F66.1080507@gmail.com/
Also on:    postgresql.org/message-id/4D4C0F66.1080507@gmail.com

 · 

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: tivv00@gmail.com, ktm@rice.edu, robertmhaas@gmail.com, jnelson+pgsql@jamponi.net, mladen.gogala@vmsinfo.com, andrew@dunslane.net, bruce@momjian.us, tgl@sss.pgh.pa.us, craig@postnewspapers.com.au
  Subject: Re: [HACKERS] Slow count(*) again...
  In-Reply-To: <4D4C0F66.1080507@gmail.com>

* 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