Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kSsIo-0001ZW-0i for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Oct 2020 01:43:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kSsIm-00035Q-Ti for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Oct 2020 01:43:32 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kSsIm-00035J-JF for pgsql-hackers@lists.postgresql.org; Thu, 15 Oct 2020 01:43:32 +0000 Received: from mail-io1-xd35.google.com ([2607:f8b0:4864:20::d35]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kSsIj-0003bt-Li for pgsql-hackers@postgresql.org; Thu, 15 Oct 2020 01:43:31 +0000 Received: by mail-io1-xd35.google.com with SMTP id g7so2254640iov.13 for ; Wed, 14 Oct 2020 18:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=BZVk1KwlN9FxQ5U3Tvxsw2g3GzJeVIqfgjFgg4Z5bWY=; b=FTjp7SfMXtBMKWcbQ1F5DK+52GbkpC0Wo+tNIAX5zwdLB7QyRjF6h71GBTHWdFBrX0 wyJ3yln8UJeameGCaqfdL+YwIcZ13ucNVbKfLdIyUEXSWb+xMNrINlzBz6a2+kbuIgbP jzs0ZXhyY2clIIhQPjymaaE5xiBVkEf7I1yRVTPA43CyZh6SmZgssoCg5Ui3y6CdhzTg Fz0iN7rqPciLg7s9P0lFc1gHvAp8MozCi7BUQJvMcM65c1PixZt9atbf7Le6bMoeHx46 mPMPWIEH3ka5JpzRlhz/KYvYyHSJH2EaQrdWVCFiHjJUqk/Q/EHxQ1n33g/kZWgzDy6r Uu9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=BZVk1KwlN9FxQ5U3Tvxsw2g3GzJeVIqfgjFgg4Z5bWY=; b=AXYCiZArbeZbdf/AkogiRJHRr/t6xLI+l/edZuGPp2UlevHBcvRgpcMkd5xBcGWcte bpJTKg2cRWIipTks6DLTMkETVTpyJaBG0bLUvwSwEzw/2fBpIX0LPmFMg4N9iVSH70I9 AS0wn9tOV0RoRiHR6cjZWooITguq4pdg+aupTxjSMaQPxisnTUKQ7ZY9Ikx/BL8RJ7VB B3JqEXk3Dn/a9qd2+Dq91OheEKhNjijAyr0tF3izzoyTTnlZsEOlWjShAt8s7uWCcWCb 6FAAIJs3N73rY0b9BdHLLd5odSHvOeSLxH8+wxHaJvRKdm9N2YQBu22ism+rBwE6KO2d j60Q== X-Gm-Message-State: AOAM530mer0tIH22QwWf2+/Q8o+/QRmz3YHngJsAhz/n4x4qcDSRNdSb lOQ9+yM78EgbRzKpdmdirTJQ4g== X-Google-Smtp-Source: ABdhPJwXQuxKJouzNkvRSwSjgO4nqL0CpnJds21WRY5NU4VpIxNVEwaOPuCEbx7wkEbUCMzexYNdAw== X-Received: by 2002:a5d:984f:: with SMTP id p15mr1619196ios.70.1602726208765; Wed, 14 Oct 2020 18:43:28 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id u3sm1315223ili.57.2020.10.14.18.43.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2020 18:43:28 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id DFF22800740; Wed, 14 Oct 2020 20:43:26 -0500 (CDT) Date: Wed, 14 Oct 2020 20:43:26 -0500 From: Justin Pryzby To: David Rowley Cc: Tom Lane , PostgreSQL-development , Andres Freund Subject: Re: jit and explain nontext Message-ID: <20201015014326.GU9241@telsasoft.com> References: <20201014193859.GS9241@telsasoft.com> <3643530.1602724513@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Oct 15, 2020 at 02:23:01PM +1300, David Rowley wrote: > On Thu, 15 Oct 2020 at 14:15, Tom Lane wrote: > > David Rowley writes: > > > Just for some reference. Some wisdom was shared in [1], which made a > > > lot of sense to me. > > > If we apply that, then we just need to decide if displaying any jit > > > related fields without any jitted expressions is relevant. > > > > Hmm, I dunno if my opinion counts as "wisdom", but what I was arguing for > > there was that we should print stuff if it's potentially invoked by a > > run-time decision, but not if it was excluded at plan time. I'm not > > totally clear on whether jitting decisions are fixed by the plan tree > > (including its cost values) or if the executor can make different > > decisions in different executions of the identical plan tree. > > If the latter, then I agree with Justin that this is a bug. > > As far as I know, the only exception where the executor overwrites the > planner's decision is in nodeValuesscan.c where it turns jit off > because each VALUES will get evaluated just once, which would be a > waste of effort to JIT. > > Apart from that the choice is baked in by the planner and set in > PlannedStmt.jitfFlags. What about the GUCs themselves ? They can change after planning, which means a given execution of a plan might or might not use jit. -- Justin