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

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: david(at)lang(dot)hm, Vitalii Tymchyshyn <tivv00(at)gmail(dot)com>, Kenneth Marshall <ktm(at)rice(dot)edu>, Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>, 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-05 08:38:40
Message-ID: AANLkTikKTc2GPm87Liztk3UTdRY+_THquaaW3qoMe2+d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On Fri, Feb 4, 2011 at 11:37 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Feb 5, 2011 at 12:46 AM,  <david(at)lang(dot)hm> wrote:
>>> 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).
>>
>> two thoughts
>>
>> 1. if it's a large enough load, itsn't it I/O bound?
>
> Sometimes.  Our COPY is not as cheap as we'd like it to be.

With a 24 drive RAID-10 array that can read at ~1GB/s I am almost
always CPU bound during copies. This isn't wholly bad as it leaves
spare IO for the rest of the machine so regular work carries on just
fine.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2011-02-05 08:49:05 Re: [HACKERS] Slow count(*) again...
Previous Message Noah Misch 2011-02-05 08:05:23 Re: ALTER TYPE 2: skip already-provable no-work rewrites

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2011-02-05 08:49:05 Re: [HACKERS] Slow count(*) again...
Previous Message Tobias Brox 2011-02-05 08:16:09 Re: table partitioning and select max(id)