Don't codegen deform code for virtual tuples in expr eval for scan fetch
Soumyadeep Chakraborty <soumyadeep2007@gmail.com>
From: Soumyadeep Chakraborty <soumyadeep2007@gmail.com>
To: pgsql-hackers@lists.postgresql.org
Date: 2019-09-18T06:54:51Z
Lists: pgsql-hackers
Attachments
- 0001-Don-t-codegen-if-tuple-is-virtual-in-expr-eval-of-sc.patch (application/octet-stream) patch 0001
- 0002-Minor-refactor-JIT-deform-or-not.patch (application/octet-stream) patch 0002
Hello Hackers, This is to address a TODO I found in the JIT expression evaluation code (opcode = EEOP_INNER_FETCHSOME/EEOP_OUTER_FETCHSOME/EEOP_SCAN_FETCHSOME): * TODO: skip nvalid check if slot is fixed and known to * be a virtual slot. Not only should we skip the nvalid check if the tuple is virtual, the whole basic block should be a no-op. There is no deforming to be done, JIT (slot_compile_deform) or otherwise (slot_getsomeattrs) for virtual tuples. Attached is a patch 0001 that achieves exactly that by: 1. Performing the check at the very beginning of the case. 2. Emitting an unconditional branch to the next opblock if we have a virtual tuple. We end up with a block with just the single unconditional branch instruction in this case. This block is optimized away when we run llvm_optimize_module(). Also enclosed is another patch 0002 that adds on some minor refactoring of conditionals around whether to JIT deform or not. --- Soumyadeep Chakraborty
Commits
-
Don't generate EEOP_*_FETCHSOME operations for slots know to be virtual.
- 36d22dd95bc8 13.0 landed
-
Reduce code duplication for ExecJust*Var operations.
- 34c9c53bb035 13.0 landed