Re: [PERFORM] pushing order by + limit to union subqueries

From: Qingqing Zhou <zhouqq(dot)postgres(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Paolo Losi <paolo(dot)losi(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PERFORM] pushing order by + limit to union subqueries
Date: 2015-04-16 18:49:25
Message-ID: CAJjS0u10Y5CjZzLd8XLCV7f=W-HHknT8AR4unQv_f5rQtbxKCw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On Sat, Feb 28, 2015 at 8:24 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> 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.
>
Yes, after pulling up, subqueries are planned independently and we
glue them together finally.

> 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 :-(
>
GreenPlum utilizes Cascades optimizer framework (also used in SQL
Server and some others) to make the optimizer more modular and
extensible. In our context here, it allows thorough optimization
without pre-defined boundaries - no "subquery planning then glue
them". Is that something in your mind?

Regards,
Qingqing

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2015-04-16 18:52:08 Re: Assertion failure when streaming logical changes
Previous Message Peter Geoghegan 2015-04-16 17:25:29 Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0

Browse pgsql-performance by date

  From Date Subject
Next Message Christian Gough 2015-04-17 18:25:15 Postgresql Host Swapping Hard With Abundant Free Memory
Previous Message Jeff Janes 2015-04-15 06:45:55 Re: PATCH: adaptive ndistinct estimator v4