| From: | Andreas Joseph Krogh <andreas(at)visena(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Sv: Re: Query is over 2x slower with jit=on |
| Date: | 2018-08-22 17:51:12 |
| Message-ID: | VisenaEmail.28.47f1027d389da54b.16562b9da65@tc7-visena |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
På onsdag 22. august 2018 kl. 18:51:55, skrev Andres Freund <andres(at)anarazel(dot)de
<mailto:andres(at)anarazel(dot)de>>:
On 2018-08-22 18:39:18 +0200, Andreas Joseph Krogh wrote:
> Just to be clear; The query really runs slower (wall-clock time), it's not
> just the timing.
I bet it's not actually running slower, it "just" takes longer to start
up due to the JITing in each worker. I suspect what we should do is to
multiple the cost limits by the number of workers, to model that. But
without the fixed instrumentation that's harder to see...
Well, yes, that might be. By "runs" I meant from me hitting ENTER in psql to
the time the query finishes...
I thought JITing of prepared queries happended once (in "prepare") so it
didn't have to do the JITing every time the query is executed. Isn't
the previously generated bytecode usable for subsequent queries?
--
Andreas Joseph Krogh
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Cramer | 2018-08-22 18:22:45 | Re: Stored procedures and out parameters |
| Previous Message | Alvaro Herrera | 2018-08-22 17:50:34 | Re: BUG #15346: Replica fails to start after the crash |