From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Lukas Fittl <lukas(at)fittl(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com> |
Subject: | Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment |
Date: | 2023-07-06 07:56:18 |
Message-ID: | 51A15CD7-E31B-483D-B911-D0EB9F5FF952@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 7 Mar 2023, at 10:51, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Sun, 5 Mar 2023 at 13:21, Lukas Fittl <lukas(at)fittl(dot)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 directly by 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2023-07-06 08:03:20 | Re: Exclusion constraints on partitioned tables |
Previous Message | Jeff Davis | 2023-07-06 07:55:14 | Re: pgsql: Fix search_path to a safe value during maintenance operations. |