Re: count(*) and bad design was: Experiences with extensibility

Поиск
Список
Период
Сортировка
От Harald Armin Massa
Тема Re: count(*) and bad design was: Experiences with extensibility
Дата
Msg-id 7be3f35d0801090404n67398980s4bc97f4e4448dcf4@mail.gmail.com
обсуждение исходный текст
Ответ на Re: count(*) and bad design was: Experiences with extensibility  (Ivan Sergio Borgonovo <mail@webthatworks.it>)
Ответы Re: count(*) and bad design was: Experiences with extensibility  (Ivan Sergio Borgonovo <mail@webthatworks.it>)
Список pgsql-general
Ivan,

> Please forgive my naiveness in this field but what does it mean an
> "exact count" and what other DB means with "an exact count" and how
> other DB deal with it?

PostgreSQL will give you an exact count of the contents of the
database as it is in the moment you begin your count. (i.e. the
transaction starts)

BUT as the table is not locked, in parallel somebody can bulkload MANY
items into the database, so at the moment (start of your transaction)
+ 1msec your count may be invalid allready.

> I'd expect it perform as good or better than other DB since now the
> bottleneck should be how efficiently it can filter records... but
> still a count(*) with a where clause will incur in the same problem
> of what "exact" means.

I know of 3 concepts to answer count() faster then PostreSQL:

1) just lie, present an estimate
2) do not have MVCC
3) store "record deleted info" in index, so you can answer count()
with only scanning the index

Harald


--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
fx 01212-5-13695179
-
EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned!

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

Предыдущее
От: Glyn Astill
Дата:
Сообщение: Startup scripts - Use -m fast or smart?
Следующее
От: Michael Glaesemann
Дата:
Сообщение: Re: Read/Write restriction mechanism