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 1nQKTH-000783-56 for pgsql-general@arkaria.postgresql.org; Sat, 05 Mar 2022 02:48:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nQKTF-0008IN-WD for pgsql-general@arkaria.postgresql.org; Sat, 05 Mar 2022 02:48:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nQKTF-0008HN-LS for pgsql-general@lists.postgresql.org; Sat, 05 Mar 2022 02:48:37 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nQKTD-00077O-Gb for pgsql-general@lists.postgresql.org; Sat, 05 Mar 2022 02:48:37 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2252mXLD4008274; Fri, 4 Mar 2022 21:48:33 -0500 From: Tom Lane To: Mladen Gogala cc: pgsql-general@lists.postgresql.org Subject: Re: Interesting fail when migrating Pg from Ubuntu Bionic to Focal In-reply-to: <780e8797-b5a8-f02f-fbea-e01b625a34a7@gmail.com> References: <20220303150428.GA26036@depesz.com> <20220303151156.GB26036@depesz.com> <20220303163921.GA10776@depesz.com> <20220303164401.GA13056@depesz.com> <3969790.1646420992@sss.pgh.pa.us> <20220304204510.GA21340@depesz.com> <3984384.1646431394@sss.pgh.pa.us> <780e8797-b5a8-f02f-fbea-e01b625a34a7@gmail.com> Comments: In-reply-to Mladen Gogala message dated "Fri, 04 Mar 2022 21:42:53 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4008272.1646448513.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 04 Mar 2022 21:48:33 -0500 Message-ID: <4008273.1646448513@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Mladen Gogala writes: > On 3/4/22 17:03, Tom Lane wrote: >> Mmm ... it might have just been that the planner chose not to use >> JIT when it thought there were fewer rows involved. Did you check >> with EXPLAIN that these cut-down cases still used JIT? > This is interesting and informative answer. How do I check whether JIT = > is used in the explain plan? Can you give me an example? If EXPLAIN prints some stuff about JIT, then JIT is going to be used, otherwise not. Here's an example from my (entirely unsuccessful) attempts to duplicate depesz's problem: =3D# explain select p.proname, (SELECT rolname from pg_catalog.pg_roles wh= ere oid =3D p.proowner) from pg_proc p; QUERY PLAN = = --------------------------------------------------------------------------= -------------------- Seq Scan on pg_proc p (cost=3D0.00..393587.22 rows=3D47243 width=3D128) SubPlan 1 -> Index Scan using pg_authid_oid_index on pg_authid (cost=3D0.28..= 8.30 rows=3D1 width=3D64) Index Cond: (oid =3D p.proowner) JIT: Functions: 8 Options: Inlining false, Optimization false, Expressions true, Deformin= g true (7 rows) regards, tom lane