| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | xinwen(at)stu(dot)scu(dot)edu(dot)cn, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17737: An assert failed in execExprInterp.c |
| Date: | 2023-01-06 00:01:08 |
| Message-ID: | 20230106000108.upiqz7vl2vwxk2p3@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2023-01-06 04:03:42 | Re: Logical Replica ReorderBuffer Size Accounting Issues |
| Previous Message | Andres Freund | 2023-01-05 21:41:49 | Re: BUG #17737: An assert failed in execExprInterp.c |