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

From: Maciek Sakrejda <maciek(at)pganalyze(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(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>, Andrei Lepikhov <lepihov(at)gmail(dot)com>
Subject: Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment
Date: 2025-04-16 16:09:41
Message-ID: CADXhmgROX1Za_fy0JJj=c7=vVE4T7XArDLHmpofHyzzfWZ+r1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 15, 2025 at 1:50 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Wed, 16 Apr 2025 at 04:25, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Mon, Apr 14, 2025 at 8:23 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > > "Estimates: capacity=N distinct keys=N lookups=N hit ratio=N.N%"
> >
> > Is lookups=N here the estimated number of lookups i.e. what we think
> > nloops will end up being?
>
> Yes. The estimate is the "calls" variable in cost_memoize_rescan(),
> which is fairly critical in the hit ratio estimate calculation.
>
> Technically this is just the Nested Loop's outer_path->rows. There was
> an argument earlier in the thread for putting this in along with the
> other fields to make things easier to read. I did argue that it was
> redundant due to the fact that the reader can look at the row estimate
> for the outer side of the Nest Loop, but maybe it's small enough to go
> in using the above format.

This kind of thing is nice to have in the text format, but it's really
nice to have when working with structured formats. Currently, to get a
loops estimate for the inner node, I need to find the parent, find the
outer node in the parent's children, and get that sibling's Plan Rows
(I think). It'd be nice to make things like that easier.

Thanks,
Maciek

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2025-04-16 16:17:53 Re: pgsql: Non text modes for pg_dumpall, correspondingly change pg_restore
Previous Message Chapman Flack 2025-04-16 15:42:27 Re: transforms [was Re: FmgrInfo allocation patterns (and PL handling as staged programming)]