Horton

Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment

Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>

View thread
From: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
To: Andrei Lepikhov <lepihov@gmail.com>, David Rowley <dgrowleyml@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Lukas Fittl <lukas@fittl.com>, Daniel Gustafsson <daniel@yesql.se>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Nikolay Samokhvalov <samokhvalov@gmail.com>
Date: 2025-07-08T13:06:05Z
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.