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

Поиск
Список
Период
Сортировка
От Ilia Evdokimov
Тема Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment
Дата
Msg-id 67b5c84a-dedd-4103-af7e-0117046102fe@tantorlabs.com
обсуждение исходный текст
Ответ на Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment  (Andrei Lepikhov <lepihov@gmail.com>)
Ответы Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment
Список pgsql-hackers
Then we need to decide clearly what exactly to display in EXPLAIN for 
the Memoize node: absolute values (estimated distinct keys and estimated 
cache capacity) or ratios (hit_ratio and evict_ratio). Ratios have the 
advantage of quickly reflecting the overall effectiveness of Memoize. 
However, absolute values have a significant advantage as they explicitly 
reveal the reason of Memoize's poor performance, making problem 
diagnosis simpler.

With absolute values, users can directly understand the underlying 
reason for poor performance. For example: insufficient memory (capacity 
< distinct keys), inaccurate planner statistics (distinct keys 
significantly different from actual values), poorly ordered keys 
(capacity ~ distinct keys, but frequent evictions as seen in the 
Evictions parameter), or Memoize simply not being beneficial (capacity ~ 
distinct keys ~ calls). Ratios, by contrast, only reflect the final 
outcome without clearly indicating the cause or the specific steps 
needed to resolve the issue.

Thus, absolute values do more than just inform users that a problem 
exists; they provide actionable details that enable users to directly 
address the problem (increase work_mem, refresh statistics, create 
extended statistics, or disable Memoize entirely). Additionally, no 
other plan nodes in PostgreSQL currently use a similar ratio-based 
approach - everywhere else absolute values are consistently shown (e.g., 
number of rows, buckets, batches, memory used, etc.). Using absolute 
values in Memoize maintains consistency with existing practice.

I've updated the patch to v5, since the new parameter est_unique_keys in 
make_memoize() is now placed near est_entries, which is more logical and 
readable than putting it at the end.

Any thoughts?

--
Best Regards,
Ilia Evdokimov,
Tantor Labs LLC.

Вложения

В списке pgsql-hackers по дате отправления: