Message-ID: <9fbe01c5cb30$4407d580$131fc39e@stratos>
From: "Cestmir Hybl" <cestmirl@freeside.sk>
To: "Steinar H. Gunderson" <sgunderson@bigfoot.com>,
	<pgsql-performance@postgresql.org>
References: <935801c5cb20$dcf93a00$131fc39e@stratos>
	<20051007104816.GA8371@uio.no>
Subject: Re: count(*) using index scan in "query often,
	update rarely" environment
Date: Fri, 7 Oct 2005 13:14:20 +0200
Organization: NUSTEP s.r.o.
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original
Content-Transfer-Encoding: 7bit

collision: it's possible to either block updating transaction until index 
scan ends or discard index scan imediately and finish query using MVCC 
compliant scan

dead rows: this sounds like more serious counter-argument, I don't know much 
about dead records management and whether it would be  possible/worth to 
make indexes matching live records when there's no transaction in progress 
on that table

----- Original Message ----- 
From: "Steinar H. Gunderson" <sgunderson@bigfoot.com>
To: <pgsql-performance@postgresql.org>
Sent: Friday, October 07, 2005 12:48 PM
Subject: Re: [PERFORM] count(*) using index scan in "query often, update 
rarely" environment


> On Fri, Oct 07, 2005 at 11:24:05AM +0200, Cestmir Hybl wrote:
>> Isn't it possible (and reasonable) for these environments to keep track 
>> of
>> whether there is a transaction in progress with update to given table and
>> if not, use an index scan (count(*) where) or cached value (count(*)) to
>> perform this kind of query?
>
> Even if there is no running update, there might still be dead rows in the
> table. In any case, of course, a new update could always be occurring 
> while
> your counting query was still running.
>
> /* Steinar */
> -- 
> Homepage: http://www.sesse.net/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster