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

From Zeugswetter Andreas DCP SD
Subject Re: gprof SELECT COUNT(*) results
Date
Msg-id E1539E0ED7043848906A8FF995BDA579A16527@m0143.s-mxs.net
Whole thread Raw
In response to gprof SELECT COUNT(*) results  (Qingqing Zhou <zhouqq@cs.toronto.edu>)
List pgsql-hackers
> DB2:
> Uncommitted Read (UR) mode "Dirty read" isn't the default, or
> the recommended lock level for most apps. I was considering
> Cursor Stability mode (or higher), which is the default

Sorry, they call it "read committed" but actually do cursor stability,
which does keep one lock on the last fetched row. Keeping the lock would

actually not be necessary to conform with ANSI "read committed".

See table 4 on Page 8 of
http://www.cs.ndsu.nodak.edu/~yawang/Snapshot.ppt

> SQLServer:
> READ COMMITTED does take share locks.

But it does not hold them. According to docu it holds them "while
reading" which
is not a very detailed description. How long is that really, e.g. with
odbc forward
cursor fetch ?

> There's a NO LOCK hint, true, but its not a default.

That is for dirty/uncommitted reads.

Andreas


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: ice-broker scan thread
Next
From: Harald Fuchs
Date:
Subject: Re: Using multi-row technique with COPY