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

Alexander Korotkov <aekorotkov@gmail.com>

From: Alexander Korotkov <aekorotkov@gmail.com>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: tharakan@gmail.com, pgsql-bugs@lists.postgresql.org, PG Bug reporting form <noreply@postgresql.org>, Tomas Vondra <tomas@vondra.me>
Date: 2025-04-21T20:23:54Z
Lists: pgsql-bugs

Attachments

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.

------
Regards,
Alexander Korotkov
Supabase

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Properly prepare varinfos in estimate_multivariate_bucketsize()

  2. Improve comments for estimate_multivariate_ndistinct()

  3. Use extended stats for precise estimation of bucket size in hash join

  4. Ignore nullingrels when looking up statistics