Other well known dbms's do have this possibility, because they place deleted or updated records in a separate table or file (plz correct me if i'm wrong). But this has other, greater performance disadvantages. The count(*) problem is a bit of a publicity problem rather than a real performance problem (i've been told). People are aware of the fact that count(*) is faster in other dbms's, but "we" don't want superficial things like optimizing count(*) for publicity ruin other, more important things for us, performance-wise.
On Sat, Mar 5, 2011 at 11:46 PM, John R Pierce <pie...@hogranch.com> wrote: > On 03/05/11 2:05 PM, Allan Kamau wrote: > >> Is it possible in theory to efficiently perform count the primary or >> unique indices underlying data structures, regardless whether there is >> a WHERE clause detailing filtration base on values from such index or >> not? >> > > indexes are not exact, due to possibly constant changes in the current > number of visible elements in the relation. > > > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- "Patriotism is the conviction that your country is superior to all others because you were born in it." -- George Bernard Shaw
