From: | "Cestmir Hybl" <cestmirl(at)freeside(dot)sk> |
---|---|
To: | "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>, <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: count(*) using index scan in "query often, update rarely" environment |
Date: | 2005-10-07 11:14:20 |
Message-ID: | 9fbe01c5cb30$4407d580$131fc39e@stratos |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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(at)bigfoot(dot)com>
To: <pgsql-performance(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2005-10-07 12:27:05 | Re: Status of Opteron vs Xeon |
Previous Message | Steinar H. Gunderson | 2005-10-07 10:48:16 | Re: count(*) using index scan in "query often, update rarely" environment |