Re: Performance of count(*)

Поиск
Список
Период
Сортировка
От Tino Wildenhain
Тема Re: Performance of count(*)
Дата
Msg-id 4602A15B.7000908@wildenhain.de
обсуждение исходный текст
Ответ на Re: Performance of count(*)  ("Craig A. James" <cjames@modgraph-usa.com>)
Ответы Re: Performance of count(*)  ("Craig A. James" <cjames@modgraph-usa.com>)
Список pgsql-performance
Craig A. James schrieb:
...
> In our case (for a variety of reasons, but this one is critical), we
> actually can't use Postgres indexing at all -- we wrote an entirely
> separate indexing system for our data, one that has the following
> properties:
>
>  1. It can give out "pages" of information (i.e. "rows 50-60") without
>     rescanning the skipped pages the way "limit/offset" would.
>  2. It can give accurate estimates of the total rows that will be returned.
>  3. It can accurately estimate the time it will take.
>

Thats certainly not entirely correct. There is no need to store or
maintain this information along with postgres when you can store
and maintain it directly in postgres as well. When you have some
outside application I think I can savely assume you are doing
less updates compared to many reads to have it actually pay out.

So why not store this information in separate "index" and "statistic"
tables? You would have just to join with your real data for retrival.

On top of that, postgres has a very flexible and extensible index
system. This would mean you save on database roundtrips and
double information storage (and the sync problems you certainly
get from it)

Regards
Tino


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

Предыдущее
От: "Craig A. James"
Дата:
Сообщение: Re: Performance of count(*)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Potential memory usage issue