Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id DD7802E0263 for ; Thu, 6 Mar 2008 02:43:21 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 12012-05 for ; Thu, 6 Mar 2008 02:43:17 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.242]) by postgresql.org (Postfix) with ESMTP id DAAE02E01EB for ; Thu, 6 Mar 2008 02:43:18 -0400 (AST) Received: by ag-out-0708.google.com with SMTP id 23so2958735agd.5 for ; Wed, 05 Mar 2008 22:43:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=1GwjloIrp/LCBzzmWFuPZM13S9R4vUO+yeD9kMj1Hgc=; b=jD2nWEfdsH81Xuh7dWtQs7ThNmSh3+IIRQ1FFE78mvauNik+8D+lkBIrxETq3ABC3cDeksqfb/H/nFzDtv+/w128esgJAcxC5u3fJMiOmx+IlTWietYGEQsiuW4EAjnQR//d6s1zEmjd9ezMrRf1J+0odRwdAGjcb2QTdLrsaP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=C7RAdJePuivJX/0WCKVuY0MOvV86EIdL7iVTa2ylU23J6zwvkzaJ3TBCzolke4hFEUylRAKWWidIWSMCQtWYy/ULS8xPKkcloOfEwLQ7urNdQGJtlMLxyPxQ8sG3xTDEkSns6OmMjN64jU684RH8iEa1HFWvGiHylMekkDDMkK8= Received: by 10.100.7.1 with SMTP id 1mr9296629ang.87.1204785797543; Wed, 05 Mar 2008 22:43:17 -0800 (PST) Received: by 10.100.105.20 with HTTP; Wed, 5 Mar 2008 22:43:17 -0800 (PST) Message-ID: Date: Thu, 6 Mar 2008 12:13:17 +0530 From: "sathiya psql" To: "A. Kretschmer" Subject: Re: count * performance issue Cc: "Mark Mielke" , pgsql-performance@postgresql.org In-Reply-To: <20080306063643.GB21084@a-kretschmer.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3596_28872007.1204785797566" References: <20080306060829.GA21084@a-kretschmer.de> <47CF8EA6.8070503@mark.mielke.cc> <20080306063643.GB21084@a-kretschmer.de> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 200803/99 X-Sequence-Number: 29053 ------=_Part_3596_28872007.1204785797566 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline is there any way to explicitly force the postgres to use index scan 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 > ------=_Part_3596_28872007.1204785797566 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline is there any way to explicitly force the postgres to use index scan

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

------=_Part_3596_28872007.1204785797566--