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.
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) |