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 5CE77D8A0D for ; Fri, 2 Sep 2005 14:55:15 -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 24894-04 for ; Fri, 2 Sep 2005 17:55:12 +0000 (GMT) Received: from cmailg1.svr.pol.co.uk (cmailg1.svr.pol.co.uk [195.92.195.171]) by svr1.postgresql.org (Postfix) with ESMTP id AC216D8A0B for ; Fri, 2 Sep 2005 14:55:07 -0300 (ADT) Received: from modem-1141.leopard.dialup.pol.co.uk ([217.135.148.117] helo=192.168.0.102) by cmailg1.svr.pol.co.uk with esmtp (Exim 4.41) id 1EBFkp-0006vt-65; Fri, 02 Sep 2005 18:55:07 +0100 Subject: Re: ORDER BY and LIMIT not propagated on inherited From: Simon Riggs To: Matteo Beccati Cc: pgsql-performance@postgresql.org In-Reply-To: <43182789.4070307@beccati.com> References: <43182789.4070307@beccati.com> Content-Type: text/plain Organization: 2nd Quadrant Date: Fri, 02 Sep 2005 18:54:56 +0100 Message-Id: <1125683697.3956.310.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.052 required=5 tests=[AWL=0.002, FORGED_RCVD_HELO=0.05] X-Spam-Level: X-Archive-Number: 200509/60 X-Sequence-Number: 14368 On Fri, 2005-09-02 at 12:20 +0200, Matteo Beccati wrote: > I'm using inherited tables to partition some data which can grow very > large. Recently I discovered that a simple query that on a regular table > would use an index was instead using seq scans (70s vs a guessed 2s). > The well known query is: > > SELECT foo FROM bar ORDER BY foo DESC LIMIT 1 > > (The same applies for SELECT MIN(foo) FROM bar using 8.1) > Returning to Matteo's original query, what we are saying is that the new optimization for MIN/MAX queries doesn't work with inherited tables. It could do, by running optimize_minmax_aggregates() for each query that gets planned to see if a better plan exists for each child table. I think that's a TODO item. Optimizing ORDER BY and LIMIT down looks like it would be harder to do in the general case, even if Matteo's simple transform looks good. I'm not sure it's a very common query type though... Best Regards, Simon Riggs