Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: gprof SELECT COUNT(*) results


  • From: "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at>
  • To: <simon(at)2ndquadrant(dot)com>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <chriskl(at)familyhealth(dot)com(dot)au>, <pgsql-hackers(at)postgresql(dot)org>, <zhouqq(at)cs(dot)toronto(dot)edu>
  • Subject: Re: gprof SELECT COUNT(*) results
  • Date: Tue, 29 Nov 2005 15:27:59 +0100
  • Message-id: <E1539E0ED7043848906A8FF995BDA579A16527(at)m0143(dot)s-mxs(dot)net>

> 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



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group