Re: JIT compiling with LLVM v9.1
От | Jeff Davis |
---|---|
Тема | Re: JIT compiling with LLVM v9.1 |
Дата | |
Msg-id | CAMp0ubch8_o=4Hj=4uyEWZ_nxigH9zoxXtvxtCpTHPfTUhcLQA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: JIT compiling with LLVM v9.1 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: JIT compiling with LLVM v9.1
|
Список | 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 по дате отправления: