Re: TupleTableSlot abstraction - Mailing list pgsql-hackers

From Andres Freund
Subject Re: TupleTableSlot abstraction
Date
Msg-id 20180818152310.6quymlphu276mpwu@alap3.anarazel.de
Whole thread Raw
In response to Re: TupleTableSlot abstraction  (Andres Freund <andres@anarazel.de>)
Responses Re: TupleTableSlot abstraction
List pgsql-hackers
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.

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.

Greetings,

Andres Freund

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: How to estimate the shared memory size required for parallel scan?
Next
From: "Jonathan S. Katz"
Date:
Subject: Re: Pre-v11 appearances of the word "procedure" in v11 docs