Re: JIT compiling with LLVM v12.2

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: JIT compiling with LLVM v12.2
Date: 2018-03-30 12:12:05
Message-ID: 70ca92e0-095b-c7a7-0e07-82dd08e42a69@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 30.03.2018 02:14, Andres Freund wrote:
> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-03-30 12:18:06 Re: [HACKERS] path toward faster partition pruning
Previous Message Aleksander Alekseev 2018-03-30 12:05:52 Re: Cast jsonb to numeric, int, float, bool