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: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>
  • Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>
  • Subject: Re: gprof SELECT COUNT(*) results
  • Date: Tue, 29 Nov 2005 09:49:57 +0100
  • Message-id: <E1539E0ED7043848906A8FF995BDA579A16447(at)m0143(dot)s-mxs(dot)net>

> > 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



Home | Main Index | Thread Index

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