Re: JIT compiling with LLVM v12.2 - Mailing list pgsql-hackers

Hi,

On 2018-03-29 19:57:42 +0700, John Naylor wrote:

Hi Andres,
I spent some time over pouring over the JIT README, and I've attached
a patch with some additional corrections as well as some stylistic
suggestions. The latter may be debatable, but I'm sure you can take
and pick as you see fit. If there are cases where I misunderstood your
intent, maybe that's also useful information. :-)

I've picked most of them, and pushed a change including some additional
changes. Thanks!

- Andres

I have repeated performance tests at my computer and find out some regression comparing with previous JIT version.
Previously JIT provides about 2 times improvement at TPC-H Q1. Now the difference is reduced to 1.4 without parallel execution and 1.3 with parallel execution:

	max_parallel_workers_per_gather=0	max_parallel_workers_per_gather=4
jit=on	17500	5730
jit=off	25100	7550

Previous my result for JIT was 13440 for sequential execution.
I know that performance is not the high priority now, it is more important to commit infrastructure.
Just want to inform that such regression takes place.
It will be nice if you can mark future directions of improving JIT performance...
postgres=# explain (analyze,buffers) select
    l_returnflag,
    l_linestatus,
    sum(l_quantity) as sum_qty,
    sum(l_extendedprice) as sum_base_price,
    sum(l_extendedprice*(1-l_discount)) as sum_disc_price,
    sum(l_extendedprice*(1-l_discount)*(1+l_tax)) as sum_charge,
    avg(l_quantity) as avg_qty,
    avg(l_extendedprice) as avg_price,
    avg(l_discount) as avg_disc,
    count(*) as count_order
from
    lineitem
where
    l_shipdate <= '1998-12-01'
group by
    l_returnflag,
    l_linestatus
order by
    l_returnflag,
    l_linestatus;
                                                                         QUERY PLAN                                           
                             
-------------------------------------------------------------------------------------------------------------------------------
------------------------------
 Finalize GroupAggregate  (cost=2064556.89..2064560.47 rows=6 width=60) (actual time=6573.905..6573.915 rows=4 loops=1)
   Group Key: l_returnflag, l_linestatus
   Buffers: shared hit=240472
   ->  Gather Merge  (cost=2064556.89..2064559.76 rows=24 width=132) (actual time=6573.888..6573.897 rows=20 loops=1)
         Workers Planned: 4
         Workers Launched: 4
         Buffers: shared hit=240472
         ->  Sort  (cost=2063556.83..2063556.85 rows=6 width=132) (actual time=6562.256..6562.256 rows=4 loops=5)
               Sort Key: l_returnflag, l_linestatus
               Sort Method: quicksort  Memory: 26kB
               Worker 0:  Sort Method: quicksort  Memory: 26kB
               Worker 1:  Sort Method: quicksort  Memory: 26kB
               Worker 2:  Sort Method: quicksort  Memory: 26kB
               Worker 3:  Sort Method: quicksort  Memory: 26kB
               Buffers: shared hit=1276327
               ->  Partial HashAggregate  (cost=2063556.69..2063556.75 rows=6 width=132) (actual time=6562.222..6562.224 rows=4
 loops=5)
                     Group Key: l_returnflag, l_linestatus
                     Buffers: shared hit=1276299
                     ->  Parallel Seq Scan on lineitem  (cost=0.00..1463755.41 rows=14995032 width=20) (actual time=312.454..25
20.753 rows=11997210 loops=5)
                           Filter: (l_shipdate <= '1998-12-01'::date)
                           Buffers: shared hit=1276299
 Planning Time: 0.130 ms
 JIT:
   Functions: 18
   Generation Time: 2.344 ms
   Inlining: true
   Inlining Time: 15.364 ms
   Optimization: true
   Optimization Time: 298.833 ms
   Emission Time: 155.257 ms
 Execution Time: 6807.751 ms
(31 rows)

Time: 6808.216 ms (00:06.808)

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company