Horton
Menu

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

Andrei Lepikhov <lepihov@gmail.com>

View thread
From: Andrei Lepikhov <lepihov@gmail.com>
To: Tomas Vondra <tomas@vondra.me>, David Rowley <dgrowleyml@gmail.com>
Cc: tharakan@gmail.com, pgsql-bugs@lists.postgresql.org, PG Bug reporting form <noreply@postgresql.org>, Alexander Korotkov <aekorotkov@gmail.com>
Date: 2025-04-16T06:57:08Z
Lists: pgsql-bugs 
On 4/15/25 15:16, Tomas Vondra wrote:
> On 4/15/25 11:41, Andrei Lepikhov wrote:
>> What do you think about that? 
> Not sure we'd want to export GroupVarInfo in the current shape. It was
> meant for a short-lived local state (within a single function), which
> seems quite different from what RestrictInfo does.
> 
> In any case, such rework seems out of scope for PG18 - it's much more
> than a fix for the bug.
Of course, it is not for PG 18. I'm working on further GROUP-BY 
optimisation where columns are re-arranged in a way to put at the first 
position column with maximum ndistinct estimation. Additional work is 
needed that may be compensated by distinct caching.
One more ongoing project - correcting ndistinct estimation by passing 
through the EquivalenceClass and looking for a minimum ndistinct. It 
also needs a kinda cache. That's why I am pondering how to redefine 
GroupVarInfo to reduce estimation efforts.

-- 
regards, Andrei Lepikhov

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