Re: gprof SELECT COUNT(*) results - Mailing list pgsql-hackers

From Zeugswetter Andreas DCP SD
Subject Re: gprof SELECT COUNT(*) results
Date
Msg-id E1539E0ED7043848906A8FF995BDA579A16447@m0143.s-mxs.net
Whole thread Raw
In response to gprof SELECT COUNT(*) results  (Qingqing Zhou <zhouqq@cs.toronto.edu>)
List pgsql-hackers
> > 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


pgsql-hackers by date:

Previous
From: "Qingqing Zhou"
Date:
Subject: Re: ice-broker scan thread
Next
From: "Mario Weilguni"
Date:
Subject: Re: Hashjoin startup strategy (was Re: Getting different number of results when using hashjoin on/off)