David Rowley <david.rowley@2ndquadrant.com> writes: > On 29 July 2018 at 17:38, Dinesh Kumar <dns98944@gmail.com> wrote: >> I found performance variance between accessing int1 and int200 column which >> is quite large.
> Have a look at slot_deform_tuple and heap_deform_tuple. You'll see > that tuples are deformed starting at the first attribute. If you ask > for attribute 200 then it must deform 1-199 first.
Note that that can be optimized away in some cases, though evidently not the one the OP is testing. From memory, you need a tuple that contains no nulls, and all the columns to the left of the target column have to be fixed-width datatypes. Otherwise, the offset to the target column is uncertain, and we have to search for it.
JIT decrease a overhead of this.
The bottleneck here is such a simple construct, I don't see how JIT could improve it by much.
And indeed, in my hands JIT makes it almost 3 times worse.
Run against ab87b8fedce3fa77ca0d6, I get 12669.619 ms for the 2nd JIT execution and 4594.994 ms for the JIT=off.
The opt1 patch did get performance back to "at least do no harm" territory, but it didn't improve over JIT=off. Adding the other two didn't get any further improvement.
I don't know where the time is going with the as-committed JIT. None of the JIT-specific timings reported by EXPLAIN (ANALYZE) add up to anything close to the slow-down I'm seeing. Shouldn't compiling and optimization time show up there?
