Re: JIT compiling with LLVM v9.1

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: JIT compiling with LLVM v9.1
Date: 2018-02-03 02:21:12
Message-ID: CAMp0ubch8_o=4Hj=4uyEWZ_nxigH9zoxXtvxtCpTHPfTUhcLQA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 29, 2018 at 1:53 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> https://git.postgresql.org/git/users/andresfreund/postgres.git

There's a patch in there to change the scan order. I suggest that you
rename the GUC "synchronize_seqscans" to something more generic like
"optimize_scan_order", and use it to control your feature as well
(after all, it's the same trade-off: weird scan order vs.
performance). Then, go ahead and commit it. FWIW I see about a 7%
boost on my laptop[1] from that patch on master, without JIT or
anything else.

I also see you dropped "7ae518bf Centralize slot deforming logic a
bit.". Was that intentional? Do we want it? I think I saw about a 2%
gain here over master, but when I applied it on top of the fast scans
it did not seem to add anything on top of fast scans. Seems
reproducible, but I don't have an explanation.

And you are probably already working on this, but it would be helpful
to get the following two patches in also:
* 3c22065f Do execGrouping via expression eval
* a9dde4aa Allow tupleslots to have a fixed tupledesc

I took a brief look at those two, but will review them in more detail.

Regards,
Jeff Davis

[1] Simple scan with simple predicate on 50M tuples, after pg_prewarm.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-02-03 03:26:59 Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Previous Message Tom Lane 2018-02-03 00:53:13 Re: [HACKERS] Re: Improve OR conditions on joined columns (common star schema problem)