Message-ID: <85307828-75da-4f5f-b3c4-d0076af05e37@gmail.com>
Date: Wed, 23 Apr 2025 08:52:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #18885: ERROR: corrupt MVNDistinct entry - 2
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: tharakan@gmail.com, pgsql-bugs@lists.postgresql.org,
 PG Bug reporting form <noreply@postgresql.org>,
 Tomas Vondra <tomas@vondra.me>
References: <18885-da51324078588253@postgresql.org>
 <ed14891b-d2ec-471a-a91f-2ea258c31795@gmail.com>
 <CAPpHfdvhz-p8Wrb0sm+c01Gk2mVR2O-mbbnXDHry4Ax=y1qSTw@mail.gmail.com>
 <c9225640-e2dc-4d9c-a598-0d1d1673b11f@gmail.com>
 <7cab95a3-0358-4102-96d1-8c94ff3c6fdb@gmail.com>
 <CAPpHfdsTQ1DAEaoGyDA8NZn-ywK4AQ0brDyiac8t=LCft0voAQ@mail.gmail.com>
Content-Language: en-AU
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: 
 <CAPpHfdsTQ1DAEaoGyDA8NZn-ywK4AQ0brDyiac8t=LCft0voAQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/85307828-75da-4f5f-b3c4-d0076af05e37%40gmail.com>
Precedence: bulk

On 4/21/25 22:23, Alexander Korotkov wrote:
> On Wed, Apr 16, 2025 at 1:00 PM Andrei Lepikhov <lepihov@gmail.com> wrote:
>> On 4/14/25 16:41, Andrei Lepikhov wrote:
>>> On 4/12/25 00:30, Alexander Korotkov wrote:
>>>> When you use add_unique_group_var() which keeps varinfos unique then
>>>> you can no longer expect that varinfos have the same order as
>>>> origin_rinfos.
>>> Ok, here is a patch that considers this issue. Now GroupVarInfo tracks
>>> source RestrictInfo. Not sure it is an ideal approach, but we don't need
>>> to synchronise the restrictions and corresponding varinfos.
>> This is the new version of the patch.
>> I don't like the previous version because it was too invasive. Also,
>> add_unique_group_var checks "known equal" keys. It is not applicable in
>> the current case, of course, but it still seems suspicious: equality
>> expressions may be applied at an upper level of the join tree, and
>> equality doesn't exist at this specific place yet. Being correct in the
>> case of GROUP-BY operator estimation, such conjecture may distort
>> estimation in the middle of the join tree.
>> With the current patch, we just stay away from that doubtful code.
> 
> This patch looks good to me.  I've added to comments to clarify the
> things and revised the commit message.  I'm going to push this if no
> objections.
Looks better than my version. No objections.

Maybe only a few words could be added - why do we initialise ndistinct 
and isdefault with these specific values: an extended statistic doesn't 
employ per-column values, and we avoid spending cycles initialising them 
with 'undefined' semantics.

-- 
regards, Andrei Lepikhov