Re: The performance issues caused by upgrading PostgreSQL to version 16.3.

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Ron Johnson <[email protected]>
To: pgsql-general <[email protected]>
Subject: Re: The performance issues caused by upgrading PostgreSQL to version 16.3.
Date: Mon, 17 Feb 2025 09:17:32 -0500
Message-ID: <CANzqJaA7uuLQnRNK6dAnbicKkL2W7LQffKzST8qrsVkTi__UTQ@mail.gmail.com> (raw)
In-Reply-To: <BJSPR01MB04988FBD8D4EBA094B62FD91E2FBA@BJSPR01MB0498.CHNPR01.prod.partner.outlook.cn>
References: <BJSPR01MB04988FBD8D4EBA094B62FD91E2FBA@BJSPR01MB0498.CHNPR01.prod.partner.outlook.cn>

On Mon, Feb 17, 2025 at 2:55 AM 馬 騰飛 <[email protected]> wrote:

> Dear PostgreSQL Community,
>
> I hope this message finds you well. I am reaching out to seek your
> technical assistance regarding a performance issue we encountered after
> upgrading our PostgreSQL version from 12.19 to 16.3.
> We have noticed a significant performance problem with a specific SQL
> query on one of our application screens.
> Interestingly, when we isolate the problematic SQL statement and replace
> its parameters with actual values, it executes in just a few seconds in
> pgAdmin.
> However, when we run the same SQL query through our application using
> Npgsql, it takes over ten minutes to complete.

We are using NpgsqlCommand.ExecuteReader to execute the SQL query, and the
> parameters are set using NpgsqlCommand.Parameters.Add.
> The main table involved in this query contains approximately 800,000
> records.
> We believe that the SQL statement itself does not have performance issues,
> but there may be problems related to how the SQL is executed in the
> application or how the parameters are set.
> However, we are unable to pinpoint the exact cause of the performance
> degradation.
>

Your situation sounds like something we encountered a few years ago in
PG12.  The solution was to add:
set plan_cache_mode = force_custom_plan

This is only for when the first five or six executions of a prepared
statement run fast, and performance drops after that.
Test the query using PREPARE (
https://www.postgresql.org/docs/16/sql-prepare.html) and ten different
parameter sets, with and without "set plan_cache_mode = force_custom_plan".

-- 
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

view thread (5+ messages)  latest in thread

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: The performance issues caused by upgrading PostgreSQL to version 16.3.
  In-Reply-To: <CANzqJaA7uuLQnRNK6dAnbicKkL2W7LQffKzST8qrsVkTi__UTQ@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