Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YRkBW-0000Dy-W6 for pgsql-performance@arkaria.postgresql.org; Sat, 28 Feb 2015 16:24:11 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YRkBV-0003TT-Qb for pgsql-performance@arkaria.postgresql.org; Sat, 28 Feb 2015 16:24:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YRkBT-0003TI-Mp for pgsql-performance@postgresql.org; Sat, 28 Feb 2015 16:24:07 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YRkBQ-0000GT-50 for pgsql-performance@postgresql.org; Sat, 28 Feb 2015 16:24:06 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id t1SGO1p5028520; Sat, 28 Feb 2015 11:24:01 -0500 From: Tom Lane To: Paolo Losi cc: pgsql-performance@postgresql.org Subject: Re: pushing order by + limit to union subqueries In-reply-to: References: Comments: In-reply-to Paolo Losi message dated "Sat, 28 Feb 2015 10:08:30 +0100" Date: Sat, 28 Feb 2015 11:24:01 -0500 Message-ID: <28519.1425140641@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Paolo Losi writes: > I've noticed that order by / limit are not distributed to union subqueries > by the planner: > Example: > q1: (select * from t1) union all (select * from t2) order by x limit 10; > q2: (select * from t1 order by x limit 10) union all (select * from t2 > order by x limit 10) > order by x limit 10; > both queries should be equivalent, but the planner provides hugely different > plans. I was expecting that the planner could rewrite the first to the > second. > Am I overlooking something? If this is the case, can anyone explain why this > optimization is not performed? There would be cases where that would be a win, and there would be cases where it wouldn't be, so I'd not be in favor of making the transformation blindly. Unfortunately, given the current state of the planner that's all we could do really, because the subqueries are planned at arm's length and then we just mechanically combine them. Doing it "right" would entail fully planning each subquery twice, which would be very expensive. I have a longstanding desire to rewrite the upper levels of the planner to use path generation and comparison, which should make it more practical for the planner to compare alternative implementations of UNION and other top-level constructs. But I've been saying I would do that for several years now, so don't hold your breath :-( regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance