| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Lukas Fittl <lukas(at)fittl(dot)com>, David Rowley <dgrowleyml(at)gmail(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-27 13:46:50 |
| Message-ID: | 81ef0f5a-b6a1-4417-ae3a-2bae9b8d419e@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 3/27/25 11:12, Ilia Evdokimov wrote:
> Memoize is unique in that it shows runtime statistics (hits, misses,
> evictions), but reveals nothing about the planner’s expectations. We
> don’t see how many distinct keys were estimated or how many entries the
> planner thought would fit in memory.
It is acceptable for me to have Memoize estimations covered by the COSTS
option.
This data may help both developers and the users. For us, it provides
information on how good group estimations are and lets us identify gaps
in the prediction code. A user may find insights about ways to optimise
the query, detecting stale statistics or defining extended statistics.
This makes it very difficult to
> understand whether Memoize was a good choice or not, or how to fix it
> when it performs poorly.
I think user already has enough data to determine whether Memoize was
the right choice - hits/misses/evictions show that.
--
regards, Andrei Lepikhov
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2025-03-27 13:48:51 | Re: Selectively invalidate caches in pgoutput module |
| Previous Message | Andres Freund | 2025-03-27 13:40:29 | Re: Draft for basic NUMA observability |