Re: TupleTableSlot abstraction - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: TupleTableSlot abstraction
Date
Msg-id CAFjFpRe82KbsBbCUUeagAoj_7MbBr_HW1J-_borLVzRjNP1BGQ@mail.gmail.com
Whole thread Raw
In response to Re: TupleTableSlot abstraction  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: TupleTableSlot abstraction
List pgsql-hackers
PFA patches rebased on ee80124811908ef1d4679296c46e36bd8a32b9de.

On Thu, Aug 9, 2018 at 5:12 PM, Ashutosh Bapat
<ashutosh.bapat@enterprisedb.com> wrote:
>>>>>>
>>>>>> 3. compile with LLVM and fix any compilation and regression errors.
>>>>>
>>>>> When I compiled server with just 0003 applied with LLVM, the
>>>>> compilation went well, but there was a server crash. That patch
>>>>> changes type of tts_nvalid from int32 to AttrNumber.

Done. Fixed the crash in the attached patch set. Thanks Andres for offlist help.

I also tried compiling the whole patch-set with LLVM. I have fixed
compilation errors in llvm_compile_expr().

The compilation errors in slot_compile_deform() requite more work.
That function accesses tuple, slow and offset properties from a
TupleTableSlot. The tuple and offset properties are now moved to
HeapTupleTableSlot so they can't be accessed from a TupleTableSlot
unless it's HeapTupleTableSlot or BufferHeapTupleTableSlot and even
then TupleTableSlot needs to be casted into a HeapTupleTableSlot for
accessing those properties. I do not know yet as to how casting works
in LLVM code. slow property of a TupleTableSlot is now available
through tts_flags. 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.

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

Attachment

pgsql-hackers by date:

Previous
From: "Shinoda, Noriyoshi (PN Japan GCS Delivery)"
Date:
Subject: [HACKERS] Proposal to add work_mem option to postgres_fdw module
Next
From: Michael Paquier
Date:
Subject: Re: Improve behavior of concurrent ANALYZE/VACUUM