Search Postgresql Archives

Re: Slow counting still true?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Em 18/09/2012 15:24, Jeff Janes escreveu:
On Mon, Sep 17, 2012 at 9:14 AM, Edson Richter <edsonrichter@xxxxxxxxxxx> wrote:

The wiki page in question has been updated today, and I see the alert in top
of page "Note that the following article only applies to versions of
PostgreSQL prior to 9.2. Index-only scans are now implemented."

So seems that traversing indexes for count(*) would be faster on 9.2, right?
Not really, as it still needs to visit some representation of every
tuple.  Now, if the entire index in is RAM while the table would not
be, it could be a lot faster.  But that is more of a special case than
a general one.

AFAIK, for count(*) doesn't matter the order data is stored - just need to
load index leaf pages and count from there, right?
That would only work if there was no concurrent activity.  If someone
else splits on index page, some of the entries on that page could move
to a location where they would get visited either zero times or two
times.
I see. This is were MS SQL Server escalates row locks into page locks, and get rid of the concurrency (at very expensive cost, IMHO).

Regards,

Edson


Cheers,

Jeff





--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux