Re: BUG #18885: ERROR: corrupt MVNDistinct entry - 2

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: tharakan(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, PG Bug reporting form <noreply(at)postgresql(dot)org>, Tomas Vondra <tomas(at)vondra(dot)me>
Subject: Re: BUG #18885: ERROR: corrupt MVNDistinct entry - 2
Date: 2025-04-16 10:00:27
Message-ID: 7cab95a3-0358-4102-96d1-8c94ff3c6fdb@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

--
regards, Andrei Lepikhov

Attachment Content-Type Size
v1-0001-Make-the-necessary-preparations-before-estimating.patch text/x-patch 4.2 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Laurenz Albe 2025-04-16 12:20:52 Re: BUG #18895: Installation failure on Fedora 42 due to missing repos
Previous Message PG Bug reporting form 2025-04-16 08:59:35 BUG #18895: Installation failure on Fedora 42 due to missing repos