Re: Wrong results from GROUP BY column removal

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: wenhui qiu <qiuwenhuifx(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Wrong results from GROUP BY column removal
Date: 2026-11-13 01:13:40
Message-ID: CAMbWs4_kpHeRY52_Bk6P6NiuSovgCbSDGsKC4O_X+__Upy=A9w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 11, 2026 at 6:17 PM wenhui qiu <qiuwenhuifx(at)gmail(dot)com> wrote:
> Just a very minor thought on the implementation: while nullable_relids is allocated in the planner context and will be reclaimed anyway, perhaps we could consider adding a bms_free(nullable_relids) before exiting remove_useless_groupby_columns(), just to stay consistent with how other temporary bitmapsets are cleaned up in that function?

I disagree. This function doesn't free any of its other bitmapsets,
so I'm not sure where you get that conclusion. Freeing just this one
would look odd. Also, I don't see the point: this one small bitmapset
has no real impact on memory usage, and it will be cleaned up along
with the planner's memory context anyway.

I've pushed 0001 as-is and back-patched it to v18.

- Richard

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-11-13 01:19:54 Re: [PATCH] Use the multirange schema for its array type name
Previous Message Ritesh Kumar 2026-11-13 01:04:28 Re: [Patch] Batch fsyncs when recycling WAL segments