Message-ID: <bc0faf78-9993-4590-bfe2-11c7a763a387@tantorlabs.com>
Date: Tue, 8 Jul 2025 16:06:05 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost
 adjustment
To: Andrei Lepikhov <lepihov@gmail.com>, David Rowley <dgrowleyml@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 Lukas Fittl <lukas@fittl.com>, Daniel Gustafsson <daniel@yesql.se>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Nikolay Samokhvalov <samokhvalov@gmail.com>
References: 
 <CAP53Pky29GWAVVk3oBgKBDqhND0BRBN6yTPeguV_qSivFL5N_g@mail.gmail.com>
 <67b5c84a-dedd-4103-af7e-0117046102fe@tantorlabs.com>
 <580fe72c-85be-45a8-9e00-6b5417690557@tantorlabs.com>
 <CAApHDvpT0Y1BfYgeWz+PkKaLBEff1izYOAjNSibhBTNFEdqLtg@mail.gmail.com>
 <CA+TgmobDHmaNTqi5yLPJoW6fTCuiWOgF9CSCSHX_OTLmGxYRUQ@mail.gmail.com>
 <CAApHDvqYL3OVvOsyvEPsDJ7h4zQh=LEygQgcQSN-TemRJLMb6Q@mail.gmail.com>
 <3ea66a50-e4b0-4f20-ae0c-4d9cbaf81cfb@tantorlabs.com>
 <CAApHDvpuM8jW-BGu7B=i6uv+jmndEo-2z_BYvj5JNmx=qV-uSQ@mail.gmail.com>
 <0e8dc4fa-3655-4e9f-9424-9b32a15e6acd@tantorlabs.com>
 <CAApHDvqmyHuEt7rdFLJr4cZecbhno5OZ6iL5EQNNu9Oi1f93sQ@mail.gmail.com>
 <7e995158-157e-4ec6-a7c8-266c1a6f7b43@tantorlabs.com>
 <CAApHDvq0Zz3+nh9hPRBP-oAocFZETfhdE_jcN8aG+Thc24Zk5g@mail.gmail.com>
 <06840539-e321-4930-9f89-cfc783c5b80a@tantorlabs.com>
 <15e0422a-31ec-4e82-b0cf-0839f636b185@tantorlabs.com>
 <5c7034c4-c48b-428b-ab3f-67f14d9f542e@tantorlabs.com>
 <6642af90-561c-4f0c-9d5b-7e288e6e7f84@gmail.com>
Content-Language: en-US
From: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
In-Reply-To: <6642af90-561c-4f0c-9d5b-7e288e6e7f84@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/bc0faf78-9993-4590-bfe2-11c7a763a387%40tantorlabs.com>
Precedence: bulk

On 07.07.2025 16:49, Andrei Lepikhov wrote:

> 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.

LGTM.

If we still don't expose any information for nodes like IncrementalSort 
that would help explain why the planner chose them, then I fully agree - 
we definitely should add it.

I suggest discussing that in a separate thread.

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