Re: gprof SELECT COUNT(*) results

> > OTOH DB2 and SQLServer take block level
> > read locks, so they can do this too, but at major loss of
concurrency
> > and threat of deadlock.

Note, that in the usual committed read isolation, they do not need to
read lock a row ! e.g. Informix only verifies, that it could lock the
row
(that there is no write lock). Only cursor stability leaves one read
lock
until the next fetch, serializable actually leaves all read locks,
and select for update an intent update lock.

Also they usually feed a buffer of rows to the client, so if the client
does a fetch it gets a row from the client side buffer. Only when the
buffer
is empty, they get more from the server.

I think the statement holds, that the optimization is pg specific,
and cannot be directly compared to other db's.

Andreas