Re: Performance difference in accessing differrent columns in a Postgres Table

From: Dinesh Kumar <dns98944(at)gmail(dot)com>
To: jeff(dot)janes(at)gmail(dot)com
Cc: andres(at)anarazel(dot)de, pavel(dot)stehule(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, david(dot)rowley(at)2ndquadrant(dot)com, pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance difference in accessing differrent columns in a Postgres Table
Date: 2018-09-05 04:21:45
Message-ID: CAEe=mR=LyA-02JDaoxX3=qV386brFrD_yCCUT+5GG_g6yvmRuQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi All,
I was wondering whether the case is solved or still continuing. As a
Postgres newbie, I can't understand any of the terms (JIT, tuple
deformation) as you mentioned above. Please anyone let me know , what is
the current scenario.

Thanks,
Dineshkumar.

On Wed, Aug 1, 2018 at 8:51 PM Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> On Mon, Jul 30, 2018 at 3:02 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
>> Hi,
>>
>> On 2018-07-30 13:31:33 -0400, Jeff Janes wrote:
>> > 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?
>>
>> As my timings showed, I don't see the slowdown you're reporting. Could
>> you post a few EXPLAIN ANALYZEs?
>>
>
>
> I don't think you showed any timings where jit_above_cost < query cost <
> jit_optimize_above_cost, which is where I saw the slow down. (That is also
> where things naturally land for me using default settings)
>
> I've repeated my test case on a default build (./configure --with-llvm
> --prefix=....) and default postgresql.conf, using the post-11BETA2 commit
> 5a71d3e.
>
>
> I've attached the full test case, and the full output.
>
> Here are the last two executions, with jit=on and jit=off, respectively.
> Doing it with TIMING OFF doesn't meaningfully change things, nor does
> increasing shared_buffers beyond the default.
>
>
>
> QUERY PLAN
>
> --------------------------------------------------------------------------------------------------------------------------
> Seq Scan on i200c200 (cost=0.00..233332.28 rows=9999828 width=16)
> (actual time=29.317..11966.291 rows=10000000 loops=1)
> Planning Time: 0.034 ms
> JIT:
> Functions: 2
> Generation Time: 1.589 ms
> Inlining: false
> Inlining Time: 0.000 ms
> Optimization: false
> Optimization Time: 9.002 ms
> Emission Time: 19.948 ms
> Execution Time: 12375.493 ms
> (11 rows)
>
> Time: 12376.281 ms (00:12.376)
> SET
> Time: 1.955 ms
> QUERY PLAN
>
> ------------------------------------------------------------------------------------------------------------------------
> Seq Scan on i200c200 (cost=0.00..233332.28 rows=9999828 width=16)
> (actual time=0.063..3897.302 rows=10000000 loops=1)
> Planning Time: 0.037 ms
> Execution Time: 4292.400 ms
> (3 rows)
>
> Time: 4293.196 ms (00:04.293)
>
> Cheers,
>
> Jeff
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff Janes 2018-09-05 16:00:59 Re: Performance difference in accessing differrent columns in a Postgres Table
Previous Message Jeff Janes 2018-09-05 00:35:19 Re: Query is slow when run for first time; subsequent execution is fast