public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ron Johnson <[email protected]>
To: pgsql-general <[email protected]>
Subject: Re: Debugging query performance in postgres
Date: Thu, 4 Sep 2025 19:21:07 -0400
Message-ID: <CANzqJaB_1B0YCMCLnY5-y3AS2jcTyzOftc3d9bs6G0On9zeTBg@mail.gmail.com> (raw)
In-Reply-To: <CAB+=1TWW+iPTtH-P+-b8CdS0fPvt2+8B7OQ5gS9ostuoPvMJqg@mail.gmail.com>
References: <CAB+=1TWW+iPTtH-P+-b8CdS0fPvt2+8B7OQ5gS9ostuoPvMJqg@mail.gmail.com>
On Thu, Sep 4, 2025 at 12:58 PM veem v <[email protected]> wrote:
> Hello,
> We have a situation in which we had a dml query within a procedure that
> was running fine but suddenly the plan flipped and it started running
> longer.
>
That sounds like something that bit me once. Took a while to figure out,
and was very puzzling.
This list explained the problem and gave me the solution. If you run the
same query multiple times in, after five executions, the PG query optimizer
decides to use a generic plan. This disables that choice to use a generic
plan:
set plan_cache_mode = force_custom_plan;
Setting that returned the procedures to their previously-rapid execution.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
view thread (5+ messages)
reply
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: [email protected]
Cc: [email protected]
Subject: Re: Debugging query performance in postgres
In-Reply-To: <CANzqJaB_1B0YCMCLnY5-y3AS2jcTyzOftc3d9bs6G0On9zeTBg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox