From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | "Voillequin, Jean-Marc" <Jean-Marc(dot)Voillequin(at)moodys(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-sql(at)lists(dot)postgresql(dot)org" <pgsql-sql(at)lists(dot)postgresql(dot)org> |
Subject: | Re: CTE materialized/not materialized |
Date: | 2020-11-27 17:03:03 |
Message-ID: | 20201127170303.GA14088@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
On 2020-Nov-27, Voillequin, Jean-Marc wrote:
> Thank you Tom & Alvaro.
> I'm still dreaming of such query planner!
An idea mentioned several times is that of making more expensive
optimizer passes for certain plans -- either at the user's request or
merely based on the initial estimated cost being very large. A query
that's seems more expensive to execute would also seem to warrant a
greater optimization effort. (But if it's automated and we get it
wrong, then we'd get complaints that we spend pointless time in the
optimizer.)
Your sample plan has 3 CTEs, so we would have to plan eight queries for
the brute-force way -- one per combination of each CTE inlined or
materialized. Maybe it's worth the optimizer cost, maybe not. Now
maybe there's a smarter approach than brute-forcing it.
From | Date | Subject | |
---|---|---|---|
Next Message | Anders Svensson | 2020-12-02 13:30:31 | Join push down on FDW partitions |
Previous Message | Voillequin, Jean-Marc | 2020-11-27 15:58:02 | RE: CTE materialized/not materialized |