From: Andrei Lepikhov <lepihov@gmail.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: tharakan@gmail.com, pgsql-bugs@lists.postgresql.org, PG Bug reporting form <noreply@postgresql.org>
Cc: Tomas Vondra <tomas@vondra.me>
Subject: Re: BUG #18885: ERROR: corrupt MVNDistinct entry - 2
Date: Wed, 23 Apr 2025 08:52:14 +0200
Message-ID: <85307828-75da-4f5f-b3c4-d0076af05e37@gmail.com> (raw)
In-Reply-To: <CAPpHfdsTQ1DAEaoGyDA8NZn-ywK4AQ0brDyiac8t=LCft0voAQ@mail.gmail.com>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: lepihov@gmail.com, aekorotkov@gmail.com, noreply@postgresql.org, tomas@vondra.me
Subject: Re: BUG #18885: ERROR: corrupt MVNDistinct entry - 2
In-Reply-To: <85307828-75da-4f5f-b3c4-d0076af05e37@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox