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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Slow count(*) again...
Дата
Msg-id AANLkTi=EkCUkQs9VTtW4aOBNNNV0gi8jYZhNgdHuFTKM@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Slow count(*) again...  (david@lang.hm)
Ответы Re: [HACKERS] Slow count(*) again...  (Scott Marlowe <scott.marlowe@gmail.com>)
Список pgsql-performance
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.

> 2. this chould be done in a separate process/thread than the load itself,
> that way the overhead of the load is just copying the data in memory to the
> other process.

I think that's more expensive than you're giving it credit for.

But by all means implement it and post the patch if it works out...!

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Предыдущее
От: david@lang.hm
Дата:
Сообщение: Re: [HACKERS] Slow count(*) again...
Следующее
От: david@lang.hm
Дата:
Сообщение: Re: getting the most of out multi-core systems for repeated complex SELECT statements