From: sathiya psql <sathiya.psql@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Fwd: count * performance issue
Date: Thu, 6 Mar 2008 12:18:25 +0530
Message-ID: <f966c2ee0803052248y3dc52fdaj1c0ece83fd66bd39@mail.gmail.com> (raw)
In-Reply-To: <f966c2ee0803052247n783dae24i9058d148bd17385e@mail.gmail.com>
References: <f966c2ee0803052142l6a105678jfe2da92a0d9371@mail.gmail.com>
<f966c2ee0803052143k4570d771o6c300647d3b987d@mail.gmail.com>
<20080306060829.GA21084@a-kretschmer.de>
<bf54be870803052215y5bb56235k5ea05ada1d701022@mail.gmail.com>
<47CF8EA6.8070503@mark.mielke.cc>
<20080306063643.GB21084@a-kretschmer.de>
<f966c2ee0803052247n783dae24i9058d148bd17385e@mail.gmail.com>
---------- Forwarded message ----------
From: sathiya psql <sathiya.psql@gmail.com>
Date: Thu, Mar 6, 2008 at 12:17 PM
Subject: Re: [PERFORM] count * performance issue
To: "A. Kretschmer" <andreas.kretschmer@schollglas.com>
Cc: psql-performance@postgresql.org
TRIGGER i can use if i want the count of the whole table, but i require for
some of the rows with WHERE condition....
so how to do that ???
On Thu, Mar 6, 2008 at 12:06 PM, A. Kretschmer <
andreas.kretschmer@schollglas.com> wrote:
> am Thu, dem 06.03.2008, um 1:26:46 -0500 mailte Mark Mielke folgendes:
> >
> >
> > There aren't a general solution. If you realy need the exact
> count of
> > tuples than you can play with a TRIGGER and increase/decrease
> the
> > tuple-count for this table in an extra table.
> >
> >
> > Of course, this means accepting the cost of obtaining update locks on
> the count
> > table.
> >
> > The original poster should understand that they can either get a fast
> estimated
> > count, or they can get a slow accurate count (either slow in terms of
> select
> > using count(*) or slow in terms of updates using triggers and locking).
> >
> > Other systems have their own issues. An index scan may be faster than a
> table
> > scan for databases that can accurately determine counts using only the
> index,
>
> No. The current index-implementation contains no information about the
> row-visibility within the current transaction. You need to scan the
> whole data-table to obtain if the current row are visible within the
> current transaction.
>
>
> > but it's still a relatively slow operation, and people don't normally
> need an
> > accurate count for records in the range of 100,000+? :-)
>
> right.
>
>
> Andreas
> --
> Andreas Kretschmer
> Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
> GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
>
> http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-performance
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: sathiya.psql@gmail.com
Subject: Re: Fwd: count * performance issue
In-Reply-To: <f966c2ee0803052248y3dc52fdaj1c0ece83fd66bd39@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox