Re: BUG #17737: An assert failed in execExprInterp.c - Mailing list pgsql-bugs

From Andres Freund
Subject Re: BUG #17737: An assert failed in execExprInterp.c
Date
Msg-id 20230106000108.upiqz7vl2vwxk2p3@awork3.anarazel.de
Whole thread Raw
In response to Re: BUG #17737: An assert failed in execExprInterp.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Hi,

On 2023-01-05 15:50:03 -0500, Tom Lane wrote:
> Otherwise, we need to either improve execGrouping.c to cope with different
> input slot types, or fix nodeRecursiveunion.c to force the supplied slot to
> be a minimal one.  That last option seems pretty hacky, and it may fail to
> cover some other case.

I'm not so sure it's a bad idea to force the "input" tuple to minimal in
nodeRecursiveunion.c. Both ->working_table and ->hashtable internally use
minimal tuples. Which afaict means we'll do the conversion twice when we don't
already have minimal tuple, which can't be good for performance. It won't
matter much if the input tuple is a heap slot, but if it's a virtual slot it's
far from cheap.

Greetings,

Andres Freund



pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: BUG #17737: An assert failed in execExprInterp.c
Next
From: Amit Kapila
Date:
Subject: Re: Logical Replica ReorderBuffer Size Accounting Issues