Re: Catching up with performance & PostgreSQL 15 - Mailing list pgsql-performance

From Andrew Dunstan
Subject Re: Catching up with performance & PostgreSQL 15
Date
Msg-id 4bc8b0d1-f2a2-5b9d-0b28-6fc7cf681eb3@dunslane.net
Whole thread Raw
In response to Re: Catching up with performance & PostgreSQL 15  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On 2022-11-30 We 11:36, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On November 30, 2022 3:47:32 AM PST, Andrew Dunstan <andrew@dunslane.net> wrote:
>>> 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.
>> The problem is that back when it was introduced these problems didn't exist to a significant degree. JIT was
developedwhen partitioning was very minimal- and the problems we're seeing are almost exclusively with queries with
manypartitions. The problems really only started much more recently. It also wasn't enabled in the first release..
 
> Well, wherever you want to pin the blame, it seems clear that we
> have a problem now.  And I don't think flipping back to off-by-default
> is the answer -- surely there is some population of users who will
> not be happy with that.  We really need to prioritize fixing the
> cost-estimation problems, and/or tweaking the default thresholds.
>
>             


+1


FTR I am not trying to pin blame anywhere. I think the work that's been
done on JIT is more than impressive.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-performance by date:

Previous
From: Igor ALBUQUERQUE SILVA
Date:
Subject: Re: Geometric types row estimation
Next
From: Paul McGarry
Date:
Subject: Odd Choice of seq scan