X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 00651D70D1 for ; Thu, 25 Aug 2005 21:27:29 -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 52378-03 for ; Fri, 26 Aug 2005 00:27:26 +0000 (GMT) Received: from mail.nordicbet.com (mail.nordicbet.com [193.69.167.130]) by svr1.postgresql.org (Postfix) with ESMTP id 3E647D703F for ; Thu, 25 Aug 2005 21:27:24 -0300 (ADT) Received: from [80.203.125.83] (helo=tobias.nordicbet.invalid) (Authenticated Sender=tobias@nordicbet.com) by mail.nordicbet.com with esmtpa (Exim 4.50 #1 (Debian)) id 1E8S1Y-00017T-Mf for ; Fri, 26 Aug 2005 02:24:59 +0200 Received: by tobias.nordicbet.invalid (Postfix, from userid 500) id 938E6DECFD; Fri, 26 Aug 2005 02:27:09 +0200 (CEST) Date: Fri, 26 Aug 2005 02:27:09 +0200 From: Tobias Brox To: pgsql-performance@postgresql.org Subject: Limit + group + join Message-ID: <20050826002709.GK10328@tobias.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Group Nordicbet User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 required=5 tests=[none] X-Spam-Level: X-Archive-Number: 200508/427 X-Sequence-Number: 14174 Consider this setup - which is a gross simplification of parts of our production system ;-) create table c (id integer primary key); create table b (id integer primary key, c_id integer); create index b_on_c on b(c_id) insert into c (select ... lots of IDs ...); insert into b (select id, id from c); /* keep it simple :-) */ Now, I'm just interessted in some few rows. All those gives good plans: explain select c.id from c order by c.id limit 1; explain select c.id from c group by c.id order by c.id limit 1; explain select c.id from c join b on c_id=c.id order by c.id limit 1; ... BUT ... combining join, group and limit makes havoc: explain select c.id from c join b on c_id=c.id group by c.id order by c.id desc limit 5; QUERY PLAN ------------------------------------------------------------------------------------- Limit (cost=3809.65..3809.67 rows=5 width=4) -> Group (cost=3809.65..3940.59 rows=26187 width=4) -> Sort (cost=3809.65..3875.12 rows=26188 width=4) Sort Key: c.id -> Hash Join (cost=559.34..1887.89 rows=26188 width=4) Hash Cond: ("outer".id = "inner".c_id) -> Seq Scan on c (cost=0.00..403.87 rows=26187 width=4) -> Hash (cost=403.87..403.87 rows=26187 width=4) -> Seq Scan on b (cost=0.00..403.87 rows=26187 width=4) (9 rows) I get the same behaviour on pg 7.4.7 and pg 8.0.2. Of course, I can probably use subqueries instead of join - though, I would have wished the planner could do better ;-) -- Notice of Confidentiality: This information may be confidential, and blah-blah-blah - so please keep your eyes closed. Please delete and destroy this email. Failure to comply will cause my lawyer to yawn.