X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 2FBDCD872E for ; Thu, 13 Oct 2005 11:11:45 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 09502-02 for ; Thu, 13 Oct 2005 14:11:38 +0000 (GMT) Received: from smtp102.rog.mail.re2.yahoo.com (smtp102.rog.mail.re2.yahoo.com [206.190.36.80]) by svr1.postgresql.org (Postfix) with SMTP id A3BC3D8651 for ; Thu, 13 Oct 2005 11:11:40 -0300 (ADT) Received: (qmail 42594 invoked from network); 13 Oct 2005 14:11:44 -0000 Received: from unknown (HELO phlogiston.dydns.org) (a.sullivan@rogers.com@209.222.54.227 with login) by smtp102.rog.mail.re2.yahoo.com with SMTP; 13 Oct 2005 14:11:44 -0000 Received: by phlogiston.dydns.org (Postfix, from userid 1000) id 8C9EC4173; Thu, 13 Oct 2005 10:11:43 -0400 (EDT) Date: Thu, 13 Oct 2005 10:11:43 -0400 From: Andrew Sullivan To: pgsql-sql@postgresql.org Subject: Re: pg, mysql comparison with "group by" clause Message-ID: <20051013141143.GA16317@phlogiston.dyndns.org> References: <3C6C2B281FD3E74C9F7C9D5B1EDA4582182614@wgexch01.wgenhq.net> <87oe5uyrfs.fsf@stark.xeocode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87oe5uyrfs.fsf@stark.xeocode.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.033 required=5 tests=[AWL=-0.017, FORGED_RCVD_HELO=0.05] X-Spam-Level: X-Archive-Number: 200510/136 X-Sequence-Number: 22989 On Thu, Oct 13, 2005 at 12:24:55AM -0400, Greg Stark wrote: > Well the "constants and the like" are precisely the point. There > are plenty of cases where adding the column to the GROUP BY is > unnecessary and since Postgres makes no attempt to prune them out, > inefficient. But inefficient pruning is an optimiser problem, not something that should lead one to invent a whole syntax change that (a) violates the standard and (b) is at least somewhat opaque in meaning. The right thing to do is surely to make the optimiser smarter, no? (Think, "What does DB2 have that we don't?") A -- Andrew Sullivan | ajs@crankycanuck.ca This work was visionary and imaginative, and goes to show that visionary and imaginative work need not end up well. --Dennis Ritchie