| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, David Rowley <dgrowleyml(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Mladen Gogala <gogala(dot)mladen(at)gmail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Catching up with performance & PostgreSQL 15 |
| Date: | 2022-11-30 16:36:28 |
| Message-ID: | 1345396.1669826188@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On November 30, 2022 3:47:32 AM PST, Andrew Dunstan <andrew(at)dunslane(dot)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 developed when partitioning was very minimal- and the problems we're seeing are almost exclusively with queries with many partitions. 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Igor ALBUQUERQUE SILVA | 2022-11-30 16:44:36 | Geometric types row estimation |
| Previous Message | Andres Freund | 2022-11-30 16:07:11 | Re: Catching up with performance & PostgreSQL 15 |