Re: JIT compiling with LLVM v9.1 - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: JIT compiling with LLVM v9.1
Date
Msg-id CAMp0ubch8_o=4Hj=4uyEWZ_nxigH9zoxXtvxtCpTHPfTUhcLQA@mail.gmail.com
Whole thread Raw
In response to Re: JIT compiling with LLVM v9.1  (Andres Freund <andres@anarazel.de>)
Responses Re: JIT compiling with LLVM v9.1
List pgsql-hackers
On Mon, Jan 29, 2018 at 1:53 AM, Andres Freund <andres@anarazel.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.


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: Improve OR conditions on joined columns (common star schema problem)
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)