Thread: is JIT available
So JIT is enabled in your conf, how can you tell from within a client session whether it's actually available (PG compiledwith it and compiler available)? (In the other discussion I started, doing a dump and import of just the tables involved, onto a system where JIT was inadvertentlynot working for some reason, lead me down a dead end for a bit.) -- Scott Ribe scott_ribe@elevated-dev.com https://www.linkedin.com/in/scottribe/
so 25. 7. 2020 v 0:49 odesílatel Scott Ribe <scott_ribe@elevated-dev.com> napsal:
So JIT is enabled in your conf, how can you tell from within a client session whether it's actually available (PG compiled with it and compiler available)?
(In the other discussion I started, doing a dump and import of just the tables involved, onto a system where JIT was inadvertently not working for some reason, lead me down a dead end for a bit.)
SELECT * FROM pg_config;
Regards
Pavel
--
Scott Ribe
scott_ribe@elevated-dev.com
https://www.linkedin.com/in/scottribe/
> On Jul 24, 2020, at 9:55 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > > SELECT * FROM pg_config; That doesn't tell me whether or not it can actually be used.
so 25. 7. 2020 v 14:04 odesílatel Scott Ribe <scott_ribe@elevated-dev.com> napsal:
> On Jul 24, 2020, at 9:55 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> SELECT * FROM pg_config;
That doesn't tell me whether or not it can actually be used.
It shows if Postgres was compiled with JIT support.
When you run EXPLAIN ANALYZE SELECT ... then you can see info about JIT overhead. If you don't see notices about JIT in EXPLAIN, then JIT was not used.
Pavel
> On Jul 25, 2020, at 6:21 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > > It shows if Postgres was compiled with JIT support. > > When you run EXPLAIN ANALYZE SELECT ... then you can see info about JIT overhead. If you don't see notices about JIT inEXPLAIN, then JIT was not used. The presence of "jit = on" in the config file does not indicate whether the running PG was actually compiled with JIT. AndI'm not sure whether beyond that, compiling with JIT requires presence of anything outside the PG install.
so 25. 7. 2020 v 14:33 odesílatel Scott Ribe <scott_ribe@elevated-dev.com> napsal:
> On Jul 25, 2020, at 6:21 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> It shows if Postgres was compiled with JIT support.
>
> When you run EXPLAIN ANALYZE SELECT ... then you can see info about JIT overhead. If you don't see notices about JIT in EXPLAIN, then JIT was not used.
The presence of "jit = on" in the config file does not indicate whether the running PG was actually compiled with JIT. And I'm not sure whether beyond that, compiling with JIT requires presence of anything outside the PG install.
select * from pg_config where name = 'CONFIGURE' and setting like '%with-llvm';
if you see one row, then your postgres should be configured and compiled with JIT support
## Scott Ribe (scott_ribe@elevated-dev.com): > So JIT is enabled in your conf, how can you tell from within a client > session whether it's actually available (PG compiled with it and > compiler available)? pg_jit_available() boolean is JIT compilation available in this session https://www.postgresql.org/docs/12/functions-info.html Regards, Christoph -- Spare Space
> On Jul 25, 2020, at 8:21 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > > > > so 25. 7. 2020 v 14:04 odesílatel Scott Ribe <scott_ribe@elevated-dev.com> napsal: > > On Jul 24, 2020, at 9:55 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote: > > > > SELECT * FROM pg_config; > > That doesn't tell me whether or not it can actually be used. > > It shows if Postgres was compiled with JIT support. > > When you run EXPLAIN ANALYZE SELECT ... then you can see info about JIT overhead. If you don't see notices about JIT inEXPLAIN, then JIT was not used. I like Pavel’s 'EXPLAIN ANALYZE SELECT’ suggestion a lot. I think setting jit=on and jit_above_cost=1 and then running 'EXPLAINANALYZE SELECT’ is a very effective way to see whether jit is available in practice. On installations where jit isn’t available (like on my Mac or on AWS Aurora), you can still set jit=on in a session and Postgresdoesn’t complain, but that doesn’t mean it’s actually enabled. Cheers Philip
> On Jul 25, 2020, at 8:02 AM, Christoph Moench-Tegeder <cmt@burggraben.net> wrote: > > ## Scott Ribe (scott_ribe@elevated-dev.com): > >> So JIT is enabled in your conf, how can you tell from within a client >> session whether it's actually available (PG compiled with it and >> compiler available)? > > pg_jit_available() boolean is JIT compilation available in this session > > https://www.postgresql.org/docs/12/functions-info.html Thanks, that seems to be exactly what I was looking for. Even though the documentation is not clear, it does return false when jit = on but PG was not compiled with JIT.
On Tue, 28 Jul 2020 at 04:18, Scott Ribe <scott_ribe@elevated-dev.com> wrote: > > > On Jul 25, 2020, at 8:02 AM, Christoph Moench-Tegeder <cmt@burggraben.net> wrote: > > pg_jit_available() boolean is JIT compilation available in this session > > > > https://www.postgresql.org/docs/12/functions-info.html > > Thanks, that seems to be exactly what I was looking for. > > Even though the documentation is not clear, it does return false when jit = on but PG was not compiled with JIT. If it's not clear we can certainly change it. I looked at the manual page. It says: "is JIT compilation available in this session (see Chapter 31)? Returns false if jit is set to false." Maybe this would be better? "returns true if jit is enabled and JIT compilation is available in this session (see Chapter 31)." Open to other suggestions. David
David Rowley <dgrowleyml@gmail.com> writes: > Maybe this would be better? > "returns true if jit is enabled and JIT compilation is available in > this session (see Chapter 31)." The general, non-hacker meaning of "jit is enabled" would seem to be pretty much what this function is already doing; and for that matter, the same can be said for "JIT compilation is available". We need something that's less tautological-looking. Maybe along the lines of "returns true if a JIT compiler extension is available and the <varname>jit</varname> parameter is set to <literal>on</literal>; when this is true, JIT compilation will be performed." ? regards, tom lane
On Tue, 28 Jul 2020 at 15:33, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > David Rowley <dgrowleyml@gmail.com> writes: > > Maybe this would be better? > > > "returns true if jit is enabled and JIT compilation is available in > > this session (see Chapter 31)." > > The general, non-hacker meaning of "jit is enabled" would seem to > be pretty much what this function is already doing; and for that > matter, the same can be said for "JIT compilation is available". > We need something that's less tautological-looking. Maybe along > the lines of > > "returns true if a JIT compiler extension is available and the > <varname>jit</varname> parameter is set to <literal>on</literal>; That's probably better. FWIW, the "jit" is already a link to the GUC docs, so I had in mind that users would have known we meant "jit" the GUC rather than "jit" the feature. Your wording will help for anyone who thinks we're talking about the feature. > when this is true, JIT compilation will be performed." I'd probably drop this part since it's not really true. The query has to exceed the cost thresholds before that'll happen. David
On Tue, 28 Jul 2020 at 15:55, David Rowley <dgrowleyml@gmail.com> wrote: > > On Tue, 28 Jul 2020 at 15:33, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > David Rowley <dgrowleyml@gmail.com> writes: > > > Maybe this would be better? > > > > > "returns true if jit is enabled and JIT compilation is available in > > > this session (see Chapter 31)." > > > > The general, non-hacker meaning of "jit is enabled" would seem to > > be pretty much what this function is already doing; and for that > > matter, the same can be said for "JIT compilation is available". > > We need something that's less tautological-looking. Maybe along > > the lines of > > > > "returns true if a JIT compiler extension is available and the > > <varname>jit</varname> parameter is set to <literal>on</literal>; > > That's probably better. FWIW, the "jit" is already a link to the GUC > docs, so I had in mind that users would have known we meant "jit" the > GUC rather than "jit" the feature. Your wording will help for anyone > who thinks we're talking about the feature. > > > when this is true, JIT compilation will be performed." > > I'd probably drop this part since it's not really true. The query has > to exceed the cost thresholds before that'll happen. I pushed a doc change for this with slightly revised wording from what you mentioned. https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=d7c8576ebe3949a644c700a9f54d88e7e373a647 David
> On Jul 27, 2020, at 6:04 PM, David Rowley <dgrowleyml@gmail.com> wrote: > > "returns true if jit is enabled and JIT compilation is available in > this session (see Chapter 31)." That is clearer. I didn't submit a suggestion myself because I'm not clear on the actual circumstances. I know it won't beavailable if: - jit is not on in config - PG was not compiled with JIT support But does compilation with JIT enable and LLVM dev tools mean that all the LLVM compilation/optimization is built into thePG binaries, or does it require LLVM presence on the machine where deployed? And if so, does the function take that intoaccount as well? I would guess the function is telling the truth under all circumstances, but I don't know for sure. Perhaps: "returns true if JIT (see Chapter 31) is available in this session. Availability of JIT requires that PG was compiledwith JIT support, JIT is enabled in config, <blah blah blah is installed???>.
> On Jul 27, 2020, at 9:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > The general, non-hacker meaning of "jit is enabled" would seem to > be pretty much what this function is already doing; and for that > matter, the same can be said for "JIT compilation is available". > We need something that's less tautological-looking. Maybe along > the lines of My problem was that it says "is enabled", then calls out just one of the conditions for it to be available, but not the otherone. Either calling out no conditions, or all of them, would be more clear.
On Wed, 29 Jul 2020 at 00:26, Scott Ribe <scott_ribe@elevated-dev.com> wrote: > But does compilation with JIT enable and LLVM dev tools mean that all the LLVM compilation/optimization is built into thePG binaries, or does it require LLVM presence on the machine where deployed? And if so, does the function take that intoaccount as well? It's not enough for just the build to have been built with jit enabled. The jit extension must also be present on the machine. I think the new wording in https://www.postgresql.org/docs/devel/functions-info.html conveys that: "Returns true if a JIT compiler extension is available (see Chapter 31) and the jit configuration parameter is set to on." David