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
