Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125])
	by mail.postgresql.org (Postfix) with ESMTP id 8D7A5CE6F1
	for <pgsql-performance@postgresql.org>;
	Fri, 15 Jun 2012 16:51:42 -0300 (ADT)
Received: from gwmta.wicourts.gov ([165.219.244.99] helo=gw.wicourts.gov)
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <Kevin.Grittner@wicourts.gov>) id 1SfcYX-000052-SM
	for pgsql-performance@postgresql.org; Fri, 15 Jun 2012 19:51:42 +0000
Received: from Courts-MTA by gw.wicourts.gov
	with Novell_GroupWise; Fri, 15 Jun 2012 14:51:29 -0500
Message-Id: <4FDB4BEE02000025000484F9@gw.wicourts.gov>
X-Mailer: Novell GroupWise Internet Agent 8.0.2 
Date: Fri, 15 Jun 2012 14:51:26 -0500
From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Benedict Holland" <benedict.m.holland@gmail.com>
Cc: <pgsql-performance@postgresql.org>
Subject: Re: Update blocking a select count(*)?
References: 
 <CAD+mzoxfm8Wa5hrekeakG_TYNd_dsTR3W3DPZEV90chuzh0N_A@mail.gmail.com>
	<CAEYLb_WqEecnjr5o0DoNh15kNF_FXGkErVKw7fCGM5xxNLmrvQ@mail.gmail.com>
	<4FDB3C0202000025000484E4@gw.wicourts.gov>
	<CAD+mzozTqB8YiFQsgxU5mMqVo01wxVE0yiwoMHD_uSfSApKt7Q@mail.gmail.com>
	<CAD+mzoykMCtGaAKN9jOyH=nDF1E=EORcs4DSAbbKwvt4jJEXsQ@mail.gmail.com>
	<4FDB40B702000025000484EE@gw.wicourts.gov>
	<CAD+mzowzWWea80Vthj_xNuiDOZzyqLpDZpjMgMSY-fHL-ewsCg@mail.gmail.com>
In-Reply-To: 
 <CAD+mzowzWWea80Vthj_xNuiDOZzyqLpDZpjMgMSY-fHL-ewsCg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Pg-Spam-Score: -4.2 (----)
X-Archive-Number: 201206/90
X-Sequence-Number: 47116

Benedict Holland <benedict.m.holland@gmail.com> wrote:
 
> I can even accept the use case that the select should block with
> an Alter Table operation if data is retrieved from the table, but
> a select count(*) only returns the number of rows and should be
> table space independent.
 
Just as an example of why the data must be scanned for transactional
behavior.  Open three connections to the same database.  On the
first, run this:
 
create table t (id int not null);
insert into t select generate_series(1, 1000000);
vacuum analyze t;
begin;
delete from t where id between 1 and 50000;
 
Then, on the second, run this:
 
begin;
insert into t select generate_series(1000001, 1000600);
 
Now, run this on each of the three connections:
 
select count(*) from t;
 
You should not get the same count on each one.  Depending on your
transactional context, you will get 950000, 1000600, or 1000000. 
Over and over as long as the modifying transactions are open.  If
you want a fast approximation:
 
select reltuples from pg_class where oid = 't'::regclass;
 reltuples 
-----------
     1e+06
(1 row)
 
-Kevin