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 5D6FED8369 for ; Thu, 13 Oct 2005 01:25:09 -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 70095-07 for ; Thu, 13 Oct 2005 04:25:04 +0000 (GMT) Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227]) by svr1.postgresql.org (Postfix) with ESMTP id AFA58D834C for ; Thu, 13 Oct 2005 01:25:04 -0300 (ADT) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1EPueG-0003V7-00; Thu, 13 Oct 2005 00:24:56 -0400 To: "Anthony Molinaro" Cc: , "Tom Lane" , "Scott Marlowe" , "Stephan Szabo" , "Rick Schumeyer" , Subject: Re: pg, mysql comparison with "group by" clause References: <3C6C2B281FD3E74C9F7C9D5B1EDA4582182614@wgexch01.wgenhq.net> In-Reply-To: <3C6C2B281FD3E74C9F7C9D5B1EDA4582182614@wgexch01.wgenhq.net> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 13 Oct 2005 00:24:55 -0400 Message-ID: <87oe5uyrfs.fsf@stark.xeocode.com> Lines: 37 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.011 required=5 tests=[AWL=0.011] X-Spam-Level: X-Archive-Number: 200510/129 X-Sequence-Number: 22982 "Anthony Molinaro" writes: > Greg, > You'll have to pardon me... > > I saw this comment: > > "I don't see why you think people stumble on this by accident. > I think it's actually an extremely common need." > > Which, if referring to the ability to have items in the select that do not > need to be included in the group, (excluding constants and the like) is just > silly. 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. And constants aren't the only such case. The most common case is columns that are coming from a table where the primary key is already included in the GROUP BY list. In the case of columns coming from a table where the primary key is already in the GROUP BY list it's possible for the database to deduce that it's unnecessary to group on that column. But it's also possible to have cases where the programmer has out of band knowledge that it's unnecessary but the database doesn't have that knowledge. The most obvious case that comes to mind is a denormalized data model that includes a redundant column. select dept_id, dept_name, count(*) from employee_list For example if dept_name is guaranteed to be the same for all records with the same dept_id. Of course that's generally considered poor design but it doesn't mean there aren't thousands of databases out there with data models like that. -- greg