MIME-Version: 1.0
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>
 <CAApHDvq+uqf3MRFb+Ai3W1k3fMnrwWBLhzUAYj3_+MM8jK32fA@mail.gmail.com>
 <34407b2d-946b-40cd-a665-49ca6af62fb9@gmail.com>
In-Reply-To: <34407b2d-946b-40cd-a665-49ca6af62fb9@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
Date: Wed, 23 Jul 2025 12:11:09 +1200
Message-ID: 
 <CAApHDvr-0MLz58OPgzFdOfVouCGFm23iO4Bn_4hLBgCLzG+==w@mail.gmail.com>
Subject: Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost
 adjustment
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>,
 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>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvr-0MLz58OPgzFdOfVouCGFm23iO4Bn_4hLBgCLzG%2B%3D%3Dw%40mail.gmail.com>
Precedence: bulk

On Wed, 23 Jul 2025 at 02:35, Andrei Lepikhov <lepihov@gmail.com> wrote:
> The 'Buffers:' way looks more natural to me. I don't like duplicated
> text in the explain format - it is already cluttered by multiple
> unnecessary elements that distract attention from the problematic plan
> elements, such as unplaggable costs output if we only need row
> predictions, '.00' in estimations, etc.

Seems logical.

> However, at first, I'd consider how it could be added to the
> IncrementalSort and HashJoin. The number of estimated groups/buckets may
> also provide some insights into the planner's decision.

Sounds like another patch for another thread.

> Will you add the ExplainOpenGroup call to the final version of the patch?

I'm leaning towards not doing that as a reader might expect all the
"Estimates" to be within that group, but the estimated cost and row
counts won't be in there. Maybe it's possible to circumvent that
expectation by naming the group something like "MemoizeEstimates", but
IMO, that seems excessive for 4 properties.

Do you have an argument in mind to support adding the group?

David