| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(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> |
| Subject: | Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment |
| Date: | 2025-07-07 13:49:58 |
| Message-ID: | 6642af90-561c-4f0c-9d5b-7e288e6e7f84@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 4/7/2025 10:30, Ilia Evdokimov wrote:
> On 01.05.2025 15:22, Ilia Evdokimov wrote:
>
>> I attached updated v9 patch with the suggested changes. The updated
>> line in the EXPLAIN looks like this:
>>
>> Text format:
>> Estimates: capacity=1 distinct keys=1 lookups=2 hit percent=50.00%
>>
>> Non-text format:
>> Estimated Capacity: 1
>> Estimated Distinct Lookup Keys: 1
>> Estimated Lookups: 2
>> Estimated Hit Percent: 50.00
>>
>> Any suggestions?
>
>
> I attached rebased v10 patch on 5a6c39b.
Exposing internal information about the estimation of the number of
groups in the Memoise node, shouldn't we do the same in even more vague
cases, such as IncrementalSort? For example, in [1] (see its
attachment), I observe that IncrementalSort is considerably better than
Sort, but has a larger cost. It would be helpful to understand if an
incorrect ngroups estimation causes this.
[1]
https://www.postgresql.org/message-id/a74d2648-c93e-4686-a8d4-2843515b8702@gmail.com
--
regards, Andrei Lepikhov
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitry Dolgov | 2025-07-07 13:58:19 | Re: Changing shared_buffers without restart |
| Previous Message | Ashutosh Bapat | 2025-07-07 13:42:50 | Re: Changing shared_buffers without restart |