Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 8072A2E027C for ; Thu, 6 Mar 2008 02:36:52 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 09130-06 for ; Thu, 6 Mar 2008 02:36:49 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by postgresql.org (Postfix) with ESMTP id 631F32E01EB for ; Thu, 6 Mar 2008 02:36:49 -0400 (AST) Received: from webserv.wug.de ([194.25.154.138]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1JX9if3yX9-0004So; Thu, 06 Mar 2008 07:36:46 +0100 Received: from kretschmer by webserv.wug.de with local (Exim 3.36 #1) id 1JX9ie-0005o7-00; Thu, 06 Mar 2008 07:36:44 +0100 Date: Thu, 6 Mar 2008 07:36:44 +0100 From: "A. Kretschmer" To: Mark Mielke , pgsql-performance@postgresql.org Subject: Re: count * performance issue Message-ID: <20080306063643.GB21084@a-kretschmer.de> References: <20080306060829.GA21084@a-kretschmer.de> <47CF8EA6.8070503@mark.mielke.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47CF8EA6.8070503@mark.mielke.cc> X-OS: Debian/GNU Linux - weil ich es mir Wert bin! User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1/kHQqy2w9uacpPeS/Z++xcTzqvhYA4JoxvD1r Y+WWdvEB1P3+fllgO5ntzdEbKxKwz+Q5JZZzv74CLwZ7gwUUxc No8Cjp10fg7FKvEUtDAwrcfRYK/6d0O X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/98 X-Sequence-Number: 29052 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