From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
---|---|
To: | Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: inefficient/wrong plan cache mode selection for queries with partitioned tables (postgresql 17) |
Date: | 2025-05-18 16:54:24 |
Message-ID: | 34dbb623-e7ef-403f-b7b1-082c856f897e@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 5/12/25 16:04, Maxim Boguk wrote:
> On Mon, May 12, 2025 at 4:48 PM Andrei Lepikhov <lepihov(at)gmail(dot)com
> If I'm not mistaken, it will work with all PG versions that are
> currently in support. What do you think?
>
>
> Such extension would be very useful (and in general - the solution based
> on the actual execution data - seems more stable/predictable than the
> plan cost based selection which is currently used by postgresql).
I've written a sketch of such an extension; see [1]. A trivial strategy
is implemented to force prepared statements to use a generic plan if the
planning time exceeds the maximum execution time.
It is just an example - it is written in plpgsql, and you can implement
alternative strategies independently.
I would be happy if it covered your use case. Any feedback is welcome.
[1] https://github.com/danolivo/pg_mentor/tree/main
--
regards, Andrei Lepikhov
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2025-05-20 14:56:29 | Re: Re: proposal: schema variables |
Previous Message | Mahdi Bahrami | 2025-05-15 16:28:50 | Database creation performance drop going from pg 14 to pg 15+ |