Hi, On 2023-02-23 13:39:14 -0500, Corey Huinker wrote: > My not-ready-for-16 work on CAST( ... ON DEFAULT ... ) involved making > FuncExpr/IoCoerceExpr/ArrayCoerceExpr have a safe_mode flag, and that > necessitates adding a reserror boolean to ExprEvalStep for subsequent steps > to test if the error happened.
I think if that requires adding a new variable to each ExprEvalStep, it's DOA. The overhead would be too high. But I don't see why it would need to be added all ExprEvalSteps instead of individual steps, or perhaps ExprEvalState? > Will that change be throwing some architectures over the 64 byte count? It would. I find the 'pahole' tool very useful for looking at struct layout. struct ExprEvalStep { intptr_t opcode; /* 0 8 */ Datum * resvalue; /* 8 8 */ _Bool * resnull; /* 16 8 */ union { struct { int last_var; /* 24 4 */ _Bool fixed; /* 28 1 */ /* XXX 3 bytes hole, try to pack */ TupleDesc known_desc; /* 32 8 */ const TupleTableSlotOps * kind; /* 40 8 */ } fetch; /* 24 24 */ ... struct { Datum * values; /* 24 8 */ _Bool * nulls; /* 32 8 */ int nelems; /* 40 4 */ MinMaxOp op; /* 44 4 */ FmgrInfo * finfo; /* 48 8 */ FunctionCallInfo fcinfo_data; /* 56 8 */ } minmax; /* 24 40 */ ... } d; /* 24 40 */ /* size: 64, cachelines: 1, members: 4 */ }; We don't have memory to spare in the "general" portion of ExprEvalStep (currently 24 bytes), as several of the type-specific portions are already 40 bytes large. Greetings, Andres Freund