On Thu, May 1, 2025 at 5:23 PM Justin Clift wrote:
> Hi all,
>
> The PostgreSQL game "Schemaverse" was removed from the PostgreSQL
> website's
> links a few months ago because it no longer had hosting.
>
> Does anyone around have spare server/vm/something that could be used to
> host it (for free
On 5/5/25 14:26, Mladen Marinović wrote:
Hi,
Mystery not solved...but identified. The pool is in transaction mode
and some connections use set enable_mergejoin=off, but they do not set
it back to on. Upon getting the connection from the pool the parameter
is still set to off causing the plan
On 2025-May-05, Mladen Marinović wrote:
> Hi,
>
> Mystery not solved...but identified. The pool is in transaction mode and
> some connections use set enable_mergejoin=off, but they do not set it back
> to on.
Maybe instead of "SET enable_mergejoin=off" these connections could be
changed to use S
Hi , wish you good lock with the "transaction mode" 🙂 if pgbouncer is not
really needed , remove and use plain connections.i have experienced
pgbouncer in session mode over 2 years with situation like "pain in the
ass" , finaly removed this bouncing layer.
_
Hi,
Mystery not solved...but identified. The pool is in transaction mode and
some connections use set enable_mergejoin=off, but they do not set it back
to on. Upon getting the connection from the pool the parameter is still set
to off causing the planner to not use this kind of join which results
Is the query using parameter markers? Is the source executing the query forcing
a "bad" data type casting?
Yahoo Mail: Search, Organize, Conquer
On Mon, May 5, 2025 at 8:52 AM, Mladen Marinović wrote:
On Mon, May 5, 2025 at 2:38 PM SERHAD ERDEM wrote:
Hi , you had better try vacuum
Hi, if you are sure that exac plans are the same , try the model of select
count (*) from type , instead of select * fromlimit;you may
understand that the problem it is due to returning rows or not.
From: Mladen Marinović
Sent: Monday
On Mon, May 5, 2025 at 2:38 PM SERHAD ERDEM wrote:
> Hi , you had better try vacuum analyze for the whole db , pgbouncer
> connection layer can not causeslow queries.
>
I did that already. But the slow query is the consequence of the different
plan, not the statistics.
> -
On Mon, May 5, 2025 at 2:36 PM Achilleas Mantzios <
a.mantz...@cloud.gatewaynet.com> wrote:
>
> On 5/5/25 13:27, Mladen Marinović wrote:
>
>
>
> On Mon, May 5, 2025 at 12:07 PM Achilleas Mantzios <
> a.mantz...@cloud.gatewaynet.com> wrote:
>
>>
>> On 5/5/25 11:00, Mladen Marinović wrote:
>>
>>
>>
Hi , you had better try vacuum analyze for the whole db , pgbouncer
connection layer can not causeslow queries.
From: Mladen Marinović
Sent: Monday, May 5, 2025 12:27 PM
To: Achilleas Mantzios
Cc: pgsql-general@lists.postgresql.org
Subject: Re: Different
On 5/5/25 13:27, Mladen Marinović wrote:
On Mon, May 5, 2025 at 12:07 PM Achilleas Mantzios
wrote:
On 5/5/25 11:00, Mladen Marinović wrote:
On Mon, May 5, 2025 at 11:24 AM Achilleas Mantzios
wrote:
On 5/5/25 09:52, Mladen Marinović wrote:
Hi,
We
On 5/5/25 11:30, Ruben Morais wrote:
HI,
Could be a hint but test with jit to off.
If not wrong as you change from 11 to 17, that could be a cause, just
try it because in some cases plans changed when jit is on.
Not only JIT but also other extensions (such as timescale) could greatly
affect
On Mon, May 5, 2025 at 12:07 PM Achilleas Mantzios <
a.mantz...@cloud.gatewaynet.com> wrote:
>
> On 5/5/25 11:00, Mladen Marinović wrote:
>
>
>
> On Mon, May 5, 2025 at 11:24 AM Achilleas Mantzios <
> a.mantz...@cloud.gatewaynet.com> wrote:
>
>>
>> On 5/5/25 09:52, Mladen Marinović wrote:
>>
>> Hi
On 5/5/25 11:00, Mladen Marinović wrote:
On Mon, May 5, 2025 at 11:24 AM Achilleas Mantzios
wrote:
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 t
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 pro
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 we
16 matches
Mail list logo
