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

From: Vitalii Tymchyshyn <tivv00(at)gmail(dot)com>
To: Kenneth Marshall <ktm(at)rice(dot)edu>
Cc: david(at)lang(dot)hm, Robert Haas <robertmhaas(at)gmail(dot)com>, Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>, Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: [HACKERS] Slow count(*) again...
Date: 2011-02-04 14:38:30
Message-ID: 4D4C0F66.1080507@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kenneth Marshall 2011-02-04 14:52:20 Re: [HACKERS] Slow count(*) again...
Previous Message Robert Haas 2011-02-04 14:37:27 Re: SSI performance

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2011-02-04 14:44:58 Re: Query performance with disabled hashjoin and mergejoin
Previous Message Mladen Gogala 2011-02-04 14:36:10 Re: Talking about optimizer, my long dream