Re: count(*) slow on large tables

Поиск
Список
Период
Сортировка
От Christopher Browne
Тема Re: count(*) slow on large tables
Дата
Msg-id m3brsydm0i.fsf@wolfe.cbbrowne.com
обсуждение исходный текст
Ответ на count(*) slow on large tables  (Dror Matalon <dror@zapatec.com>)
Список pgsql-performance
In the last exciting episode, jllachan@nsd.ca (Jean-Luc Lachance) wrote:
> Well I can think of many more case where it would be usefull:
>
> SELECT COUNT(DISTINCT x) FROM ...
> SELECT COUNT(*) FROM ... WHERE x = ?

Those are precisely the cases that the "other databases" ALSO fall
down on.

Maintaining those sorts of statistics would lead [in _ANY_ database;
PostgreSQL has no disadvantage in this] to needing for each and every
update to update a whole host of statistic values.

It would be fairly reasonable to have a trigger, in PostgreSQL, to
manage this sort of information.  It would not be outrageously
difficult to substantially improve performance of queries, at the
considerable cost that each and every update would have to update a
statistics table.

If you're doing a whole lot of these sorts of queries, then it is a
reasonable idea to create appropriate triggers for the (probably very
few) tables where you are doing these counts.

But the notion that this should automatically be applied to all tables
always is a dangerous one.  It would make update performance Suck
Badly, because the extra statistical updates would be quite expensive.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://www3.sympatico.ca/cbbrowne/multiplexor.html
I'm sorry Dave, I can't let you do that.
Why don't you lie down and take a stress pill?

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

Предыдущее
От: Dror Matalon
Дата:
Сообщение: Re: Speeding up Aggregates
Следующее
От: Christopher Browne
Дата:
Сообщение: Re: reindex/vacuum locking/performance?