Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment
От | Robert Haas |
---|---|
Тема | Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment |
Дата | |
Msg-id | CA+TgmoaYA6hy6hynQZ_Lwk-_HkhXhH6oDGSPFLQjcDgL0kSFcQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment (Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>) |
Список | pgsql-hackers |
On Thu, Mar 27, 2025 at 6:12 AM Ilia Evdokimov <ilya.evdokimov@tantorlabs.com> wrote: > I understand the concerns raised about the risk of opening the door to more diagnostic detail across various plan nodes.However, in Hash Join, Merge Join, and Nested Loop, EXPLAIN typically reveals at least some of the planner’s expectations.For example, Hash Join shows the number of batches and originally expected buckets, giving insight into whetherthe hash table fit in memory. Merge Join shows unexpected Sort nodes when presorted inputs were assumed. Nested Loopreflects planner assumptions via loops and row estimates. In other words, these nodes expose at least some informationabout what the planner thought would happen. > > Memoize is unique in that it shows runtime statistics (hits, misses, evictions), but reveals nothing about the planner’sexpectations. We don’t see how many distinct keys were estimated or how many entries the planner thought would fitin memory. This makes it very difficult to understand whether Memoize was a good choice or not, or how to fix it whenit performs poorly. Right. Without taking a strong position on this particular patch, I think it's entirely reasonable, as a concept, to think of making Memoize work similarly to what other nodes already do. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: