| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
| Date: | 2021-02-23 05:43:47 |
| Message-ID: | 3795226.1614059027@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> We could add a wrapper node around "planner expressions" that stores
> metadata about them during planning, without those properties leaking
> over expressions used at other times. E.g. having
> preprocess_expression() return a PlannerExpr that that points to the
> expression as preprocess_expression returns it today. That'd make it
> easy to cache information like volatility. But it also seems
> prohibitively invasive :(.
I doubt it's that bad. We could cache such info in RestrictInfo
for quals, or PathTarget for tlists, without much new notational
overhead. That doesn't cover everything the planner deals with
of course, but it would cover enough that you'd be chasing pretty
small returns to worry about more.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2021-02-23 05:50:41 | Re: pg_temp_%d namespace creation can invalidate all the cached plan in other backends |
| Previous Message | Andy Fan | 2021-02-23 04:14:50 | Re: pg_temp_%d namespace creation can invalidate all the cached plan in other backends |