Re: TupleTableSlot abstraction

On Sat, Aug 18, 2018 at 8:53 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2018-08-17 01:07:06 -0700, Andres Freund wrote:
>> Hi,
>>
>> On 2018-08-17 12:10:20 +0530, Ashutosh Bapat wrote:
>> > We need to add LLVM code to fetch tts_flags and
>> > perform bit operation on it to get or set slow property. I haven't
>> > found any precedence for LLVM bit operations in postgresql's JIT code.
>>
>> There are several, look for the infomask accesses in
>> slot_compiler_deform.
>>
>> I'll try to do the adaption later today.
>
> Attached is a series of patches doing so. The previous implementation
> of sysvar accesses wasn't actually working - the slot argument was
> uninitialized.

Sorry for that. I couldn't test it since the code wasn't compiling.
The changes to slot_compile_deform changes you provided in the patch
fix the compilation errors. Thanks for those changes.

>
> I also noticed an independent issue in your changes to
> ExecInitScanTupleSlot(): You can't assume that the plan belonging to the
> ScanState have a Scan node in their plan. Look e.g. at Material, Sort
> etc. So currently your scanrelid access is often just uninitialized
> data.

I have incorporated changes in your patches into the relevant patches
in the updated patch-set. With this patch-set make check-world passes
for me.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company