| From: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
|---|---|
| To: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Lukas Fittl <lukas(at)fittl(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-07-08 13:06:05 |
| Message-ID: | bc0faf78-9993-4590-bfe2-11c7a763a387@tantorlabs.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 07.07.2025 16:49, Andrei Lepikhov wrote:
> Exposing internal information about the estimation of the number of
> groups in the Memoise node, shouldn't we do the same in even more
> vague cases, such as IncrementalSort? For example, in [1] (see its
> attachment), I observe that IncrementalSort is considerably better
> than Sort, but has a larger cost. It would be helpful to understand if
> an incorrect ngroups estimation causes this.
LGTM.
If we still don't expose any information for nodes like IncrementalSort
that would help explain why the planner chose them, then I fully agree -
we definitely should add it.
I suggest discussing that in a separate thread.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2025-07-08 13:21:04 | Re: amcheck support for BRIN indexes |
| Previous Message | Andres Freund | 2025-07-08 12:56:06 | Re: Adding basic NUMA awareness |