From: Andrew Dunstan <andrew@dunslane.net>
To: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Andres Freund <andres@anarazel.de>
Cc: Mladen Gogala <gogala.mladen@gmail.com>
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: Catching up with performance & PostgreSQL 15
Date: Wed, 30 Nov 2022 06:47:32 -0500
Message-ID: <18d8cac2-36fa-3736-fa4a-c33c290301cb@dunslane.net> (raw)
In-Reply-To: <CAApHDvoT4KXjNGos8FvMt5NvzvWJrkzs1oqFp6J4vAb==Q=DBA@mail.gmail.com>
References: <20221129083615.fseqfvd5svtjbrb6@alvherre.pgsql>
<871130.1669732296@sss.pgh.pa.us>
<CAApHDvoT4KXjNGos8FvMt5NvzvWJrkzs1oqFp6J4vAb==Q=DBA@mail.gmail.com>
On 2022-11-29 Tu 16:06, David Rowley wrote:
> On Wed, 30 Nov 2022 at 03:31, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
> I'm very grateful for JIT. However, I do agree that the costs need to work.
>
> The problem is that the threshold to turn JIT on does not consider how
> many expressions need to be compiled. It's quite different to JIT
> compile a simple one-node plan with a total cost of 100000 than to JIT
> compile a plan that costs the same but queries 1000 partitions. I
> think we should be compiling expressions based on the cost of the
> individial node rather than the total cost of the plan. We need to
> make some changes so we can more easily determine the number of times
> a given node will be executed before we can determine how worthwhile
> JITting an expression in a node will be.
>
I think Alvaro's point is that it would have been better to work out
these wrinkles before turning on JIT by default. Based on anecdotal
reports from the field I'm inclined to agree.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
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-performance@postgresql.org
Cc: andrew@dunslane.net, dgrowleyml@gmail.com, tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, andres@anarazel.de, gogala.mladen@gmail.com, pgsql-performance@lists.postgresql.org
Subject: Re: Catching up with performance & PostgreSQL 15
In-Reply-To: <18d8cac2-36fa-3736-fa4a-c33c290301cb@dunslane.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