| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me>, David Rowley <dgrowleyml(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>, Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
| Subject: | Re: BUG #18885: ERROR: corrupt MVNDistinct entry - 2 |
| Date: | 2025-04-16 06:57:08 |
| Message-ID: | 1ebbf4dc-2b7e-43b0-a1a5-c0d7799c9ef2@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2025-04-16 08:59:35 | BUG #18895: Installation failure on Fedora 42 due to missing repos |
| Previous Message | David Rowley | 2025-04-16 04:11:42 | Re: BUG #18885: ERROR: corrupt MVNDistinct entry - 2 |