From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Andres Freund <andres@anarazel.de>,
        Mladen Gogala <gogala.mladen@gmail.com>,
        pgsql-performance@lists.postgresql.org
Subject: Re: Catching up with performance & PostgreSQL 15
In-reply-to: <20221129083615.fseqfvd5svtjbrb6@alvherre.pgsql>
References: <20221129083615.fseqfvd5svtjbrb6@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Tue, 29 Nov 2022 09:36:15 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <871129.1669732296.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 29 Nov 2022 09:31:36 -0500
Message-ID: <871130.1669732296@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/871130.1669732296%40sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> IMO it was a mistake to turn JIT on in the default config, so that's one
> thing you'll likely want to change.

I wouldn't necessarily go quite that far, but I do think that the
default cost thresholds for invoking it are enormously too low,
or else there are serious bugs in the cost-estimation algorithms
for deciding when to use it.  A nearby example[1] of a sub-1-sec
partitioned query that took 30sec after JIT was enabled makes me
wonder if we're accounting correctly for per-partition JIT costs.

			regards, tom lane

[1] https://www.postgresql.org/message-id/B6025887-D73F-4B5B-9925-4DA4B675=
F7E5%40elevated-dev.com