Re: Different execution plans in PG17 and pgBouncer...

On 5/5/25 09:52, Mladen Marinović wrote:
> Hi,
>
> We recently migrated our production instances from PG11 to PG17. While
> doing so we upgraded our pgBouncer instances from 1.12 to 1.24. As
> everything worked on the test servers we pushed this to production a
> few weeks ago. We did not notice any problems until a few days ago
> (but the problems were here from the start). The main manifestation of
> the problems is a service that runs a fixed query to get a backlog of
> unprocessed data (limited to a 1000 rows). When testing the query
> using pgAdmin connected directly to the database we get a result in
> cca. 20 seconds. The same query runs for 2 hours when using pgBouncer
> to connect to the same database.

That's a huge jump, I hope you guys did extensive testing of your app.
In which language is your app written? If java, then define
prepareThreshold=0 in your jdbc and set max_prepared_statements = 0 in
pgbouncer.

How about search paths ? any difference on those between the two runs ?
Do you set search_path in pgbouncer ? what is "cca." btw ?

>
> The more interesting part is that when we issue an explain of the same
> query we get different plans. We did this a few seconds apart so there
> should be no difference in collected statistics. We ruled out prepared
> statements, as we suspected the generic plan might be the problem, but
> it is not. Is there any pgBouncer or PG17 parameter that might be the
> cause of this?

Does this spawn any connections (such as dblink) ? are there limits per
user/db pool_size in pgbouncer ?

Pgbouncer, in contrast to its old friend PgPool-II is completely
passive, just passes through SQL to the server as fast as possible as it
can. But I am sure you know that. Good luck, keep us posted!

>
> Regards,
> Mladen Marinović