X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id B225CD1EDD7 for ; Sun, 28 Mar 2004 06:53:37 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 45664-08 for ; Sun, 28 Mar 2004 02:53:27 -0400 (AST) Received: from smtp.istop.com (unknown [66.11.168.194]) by svr1.postgresql.org (Postfix) with ESMTP id A7254D1EDD1 for ; Sun, 28 Mar 2004 02:53:20 -0400 (AST) Received: from stark.xeocode.com (gsstark.mtl.istop.com [66.11.160.162]) by smtp.istop.com (Postfix) with ESMTP id 6D07917C4CC; Sun, 28 Mar 2004 01:53:02 -0500 (EST) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1B7TpT-0004uU-00; Sun, 28 Mar 2004 01:31:31 -0500 To: josh@agliodbs.com Cc: "Richard Sydney-Smith" , Subject: Re: Slow sub-selects, max and count(*) References: <001001c3eb8a$255d6dc0$5801a8c0@athlon2000> <200402042113.01369.josh@agliodbs.com> In-Reply-To: <200402042113.01369.josh@agliodbs.com> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 28 Mar 2004 01:31:31 -0500 Message-ID: <87brmhtrcs.fsf@stark.xeocode.com> Lines: 23 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200403/261 X-Sequence-Number: 17360 Josh Berkus writes: > Max() and Count() cannot use indexes for technical reasons. Browse through > the archives of SQL, PERFORM, and HACKERS for about 12,000 discussions on the > subject. Please don't confuse the issue by throwing Max() and Count() into the same basket. The issue with Min()/Max() is that the result could be generated efficiently by scanning indexes but it's just hard, especially given generic aggregate functions, and the work simply hasn't been done, or even started, yet. The issue with Count() is that people want the result to be cached in a single per-table counter, but that can't be done as simply as that because of transactions. People have discussed complex solutions to this but it's a much more complex problem than it appears. They're really two entirely separate issues. -- greg