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" <[EMAIL PROTECTED]>
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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
