On Fri, Oct 07, 2005 at 12:48:16PM +0200, Steinar H. Gunderson wrote:
> 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 n
On 10/7/05, Cestmir Hybl <[EMAIL PROTECTED]> wrote:
No, I can't speed-up evaluation of generic
"count(*) where ()" queries this way.
no you can't speed up generic where(), *but* you can check what are the
most common "where"'s (like usually i do where on one column like:
select count(*) from table
Tom Lane wrote:
There's a workable-looking design in the archives (pghackers probably)
for maintaining overall table counts in a separate table, with each
transaction adding one row of "delta" information just before it
commits. I haven't seen anything else that looks remotely attractive.
It
On 10/7/05, Cestmir Hybl <[EMAIL PROTECTED]> 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 quer
"Cestmir Hybl" <[EMAIL PROTECTED]> writes:
> 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
On Fri, Oct 07, 2005 at 01:14:20PM +0200, Cestmir Hybl wrote:
> 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
You can't change from one scan method to a different one on the fly.
t 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:
Sent: Friday, October 07, 2005 12:48 PM
Subject: Re: [PERFORM] count(*) u
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
count() queries in environment with infrequent updates.
Cestmir
- Original Message -
From:
hubert depesz
lubaczewski
To: Cestmir Hybl
Cc: pgsql-performance@postgresql.org
Sent: Friday, October 07, 2005 11:54
AM
Subject: Re: [PERFORM] count(*) using
index
On 10/7/05, Cestmir Hybl <[EMAIL PROTECTED]> 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 q
Hello all
First of all, I do understand why pgsql with it's
MVCC design has to examine tuples to evaluate "count(*)" and "count(*)
where (...)" queries in environment with heavy concurrent updates.
This kind of usage IMHO isn't the average one.
There are many circumstances with rather "qu
11 matches
Mail list logo
