> On 7 Mar 2023, at 10:51, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Sun, 5 Mar 2023 at 13:21, Lukas Fittl <lukas@fittl.com> wrote:
>> Alternatively (or in addition) we could consider showing the "ndistinct" value that is calculated in
cost_memoize_rescan- since that's the most significant contributor to the cache hit ratio (and you can influence that
directlyby improving the ndistinct statistics).
>
> I think the ndistinct estimate plus the est_entries together would be
> useful. I think showing just the hit ratio number might often just
> raise too many questions about how that's calculated. To calculate the
> hit ratio we need to estimate the number of entries that can be kept
> in the cache at once and also the number of input rows and the number
> of distinct values. We can see the input rows by looking at the outer
> side of the join in EXPLAIN, but we've no idea about the ndistinct or
> how many items the planner thought could be kept in the cache at once.
>
> The plan node already has est_entries, so it should just be a matter
> of storing the ndistinct estimate in the Path and putting it into the
> Plan node so the executor has access to it during EXPLAIN.
Lukas: do you have an updated patch for this commitfest to address David's
comments?
--
Daniel Gustafsson
