On Mon, Jul 30, 2018 at 12:01 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote:
> > > 2018-07-30 13:19 GMT+02:00 Jeff Janes <jeff.ja...@gmail.com>: > >> On Mon, Jul 30, 2018 at 12:11 AM, Pavel Stehule <pavel.steh...@gmail.com> >> wrote: >> >>> 2018-07-30 1:00 GMT+02:00 Tom Lane <t...@sss.pgh.pa.us>: >>> >>>> David Rowley <david.row...@2ndquadrant.com> writes: >>>> > On 29 July 2018 at 17:38, Dinesh Kumar <dns98...@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. >> > > look on http://www.postgresql-archive.org/PATCH-LLVM-tuple- > deforming-improvements-td6029385.html thread, please. > > 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? Cheers, Jeff
