| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Lukas Fittl <lukas(at)fittl(dot)com> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> |
| Subject: | Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment |
| Date: | 2025-03-24 22:45:54 |
| Message-ID: | 1164845.1742856354@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Lukas Fittl <lukas(at)fittl(dot)com> writes:
> The main argument I had initially when proposing this, is that Memoize is
> different from other plan nodes, in that it makes the child node costs
> "cheaper". Clearly seeing the expected cache hit/ratio (that drives that
> costing modification) helps interpret why the planner came up with a given
> plan.
Memoize is hardly unique in that respect. Merge Join sometimes
expects that it won't have to read the inner input to completion,
and reduces its cost estimate accordingly, and that confuses people.
LIMIT also reduces the cost estimate of its input, though perhaps
that doesn't surprise people.
As I said, I'm not necessarily averse to showing these numbers
somehow. But I don't think they belong in the default output,
and I'm not even convinced that VERBOSE is the right place.
pg_overexplain seems like it could be an ideal home for this
sort of detail.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2025-03-24 22:55:22 | Re: AIO v2.5 |
| Previous Message | Lukas Fittl | 2025-03-24 22:30:03 | Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment |