From: | "Finnerty, Jim" <jfinnert(at)amazon(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Darafei Komяpa Praliaskouski <me(at)komzpa(dot)net> |
Cc: | 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 01:19:41 |
Message-ID: | FBD5010F-DF47-4C24-B7B8-ABF6031A69D1@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
On 9/23/19, 8:59 AM, "Robert Haas" <robertmhaas(at)gmail(dot)com> wrote:
On Sun, Sep 22, 2019 at 7:47 AM Darafei "Komяpa" Praliaskouski
<me(at)komzpa(dot)net> wrote:
> A heuristic I believe should help my case (and I hardly imagine how it can break others) is that in presence of Gather, all the function calls that are parallel safe should be pushed into it.
The cost of pushing data through the Sort is not necessarily
insignificant. Your functions are (IIUC) extremely expensive, so it's
worth going to any length to reduce the time spent evaluating them.
However, if someone has ||(text,text) in the tlist, that might be the
wrong approach, because it's not saving much to compute that earlier
and it might make the sort a lot wider, especially if de-TOASTing is
involved.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-09-24 01:40:19 | Re: PATCH: standby crashed when replay block which truncated in standby but failed to truncate in master node |
Previous Message | Peter Geoghegan | 2019-09-24 00:13:32 | Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index. |