Re: TupleTableSlot abstraction

From: Andres Freund <andres(at)anarazel(dot)de>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: TupleTableSlot abstraction
Date: 2018-08-18 15:23:10
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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

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


Andres Freund

Attachment Content-Type Size
0001-Fix-slot-type-used-in-subqueryscan.patch text/x-diff 981 bytes
0002-XXX-Copy-slot-in-nodeMaterial.c.patch text/x-diff 1018 bytes
0003-Fix-JIT-calls-to-ExecEvalSysVar.patch text/x-diff 3.0 KB
0004-First-attempt-at-support-JITing-of-tuple-deforming-w.patch text/x-diff 10.4 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2018-08-18 17:37:59 Re: Pre-v11 appearances of the word "procedure" in v11 docs
Previous Message Thomas Munro 2018-08-18 14:07:54 Re: How to estimate the shared memory size required for parallel scan?