| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | "Finnerty, Jim" <jfinnert(at)amazon(dot)com> |
| Cc: | Darafei Komяpa Praliaskouski <me(at)komzpa(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Unwanted expression simplification in PG12b2 |
| Date: | 2019-09-24 16:01:42 |
| Message-ID: | CA+TgmobyFoj3dy+mLbdp_51HG00V=3CbjPBk9sM84U1actC=7Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Sep 23, 2019 at 9:20 PM Finnerty, Jim <jfinnert(at)amazon(dot)com> wrote:
> If the function was moved to the FROM clause where it would be executed as a lateral cross join instead of a target list expression, how would this affect the cost-based positioning of the Gather?
I think you'd end up turning what is now a Seq Scan into a Nested Loop
with a Seq Scan on one side. I think the computation of the target
list would be done by the Function Scan or Result node on the other
side of the Nested Loop, and couldn't move anywhere else. The planner
would consider putting the Gather either on top of the Nested Loop or
on top of the Seq Scan, and the former would probably win. So I think
this would give the desired behavior, but I haven't thought about it
very hard.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-09-24 16:43:17 | Re: PostgreSQL12 and older versions of OpenSSL |
| Previous Message | Etsuro Fujita | 2019-09-24 15:59:57 | Re: [HACKERS] advanced partition matching algorithm for partition-wise join |