From: Stephen Frost <sfrost@snowman.net>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Khandekar <amitdkhan.pg@gmail.com>
Cc: Andreas Joseph Krogh <andreas@visena.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Jonathan S. Katz <jkatz@postgresql.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Query is over 2x slower with jit=on
Date: Thu, 20 Sep 2018 13:34:27 -0400
Message-ID: <20180920173426.GS4184@tamriel.snowman.net> (raw)
In-Reply-To: <20180920172701.dtiwldlgkkhpvykz@alap3.anarazel.de>
References: <CAJ3gD9cv2cbJ2t5zRZiWapNeRdgpM70++f80NbLwbEpM7uX2AQ@mail.gmail.com>
<20180910160909.qf3h3ttztvbyyuds@alap3.anarazel.de>
<CAJ3gD9fJcYofmWCe9hJ9Y6dUYU-qpkR=Bii+NhYufE7Mny9AHw@mail.gmail.com>
<CAJ3gD9cWBKnzXkhu30njaY1au3NO0XD=r4N3GcC_nwFbw5GYYw@mail.gmail.com>
<27812.1537221015@sss.pgh.pa.us>
<20180919224047.mcdjwis56ywqzhzs@alap3.anarazel.de>
<11291.1537414012@sss.pgh.pa.us>
<20180920033922.zi6n6vk7ilxaseu3@alap3.anarazel.de>
<20180920130721.GM4184@tamriel.snowman.net>
<20180920172701.dtiwldlgkkhpvykz@alap3.anarazel.de>
Greetings,
* Andres Freund (andres@anarazel.de) wrote:
> On 2018-09-20 09:07:21 -0400, Stephen Frost wrote:
> > * Andres Freund (andres@anarazel.de) wrote:
> > > FWIW, not that I want to do that now, but at some point it might make
> > > sense to sub-divide this into things like number of "expressions",
> > > "tuple deforming", "plans", ... Just mentioning that if somebody wants
> > > to comment on reformatting this as well, if we're tinkering anyway.
> >
> > I'd actually think we'd maybe want some kind of 'verbose' mode which
> > shows exactly what got JIT'd and what didn't- one of the questions that
> > I think people will be asking is "why didn't X get JIT'd?" and I don't
> > think that's very easy to figure out currently.
>
> That seems largely a separate discussion / feature though, right? I'm
> not entirely clear what precisely you mean with "why didn't X get
> JIT'd?" - currently that's a whole query decision.
There are things that can't be JIT'd currently and, I'm thinking anyway,
we'd JIT what we are able to and report out what was JIT'd in some
fashion which would inform a user what was able to be JIT'd and what
wasn't. I'll admit, perhaps this is more of a debugging tool than
something that a end-user would find useful, unless there's possibly
some way that a user could effect what happens.
> > > I'm pretty certain you're right :). There's already arguments around
> > > making optimization more gradual (akin to O1,2,3).
> >
> > That certainly sounds like it'd be very neat to have though I wonder how
> > well we'll be able to automatically plan out which optimization level to
> > use when..
>
> Well, that's not really different from having to decide whether to use
> JIT or not. I suspect that once / if we get caching and/or background
> JIT compilation, we can get a lot more creative around this.
yeah, I definitely understand that, cacheing, in particular, I would
expect to play a very large role.
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, andres@anarazel.de, tgl@sss.pgh.pa.us, amitdkhan.pg@gmail.com, andreas@visena.com, robertmhaas@gmail.com, alvherre@2ndquadrant.com, jkatz@postgresql.org, pgsql-hackers@lists.postgresql.org
Subject: Re: Query is over 2x slower with jit=on
In-Reply-To: <20180920173426.GS4184@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox