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

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: [HACKERS] Slow count(*) again...
Дата
Msg-id AANLkTikKTc2GPm87Liztk3UTdRY+_THquaaW3qoMe2+d@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Slow count(*) again...  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Slow count(*) again...  (Greg Smith <greg@2ndquadrant.com>)
Список pgsql-performance
On Fri, Feb 4, 2011 at 11:37 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, Feb 5, 2011 at 12:46 AM,  <david@lang.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.

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tobias Brox
Дата:
Сообщение: Re: table partitioning and select max(id)
Следующее
От: Greg Smith
Дата:
Сообщение: Re: table partitioning and select max(id)