From: | "James Pang (chaolpan)" <chaolpan(at)cisco(dot)com> |
---|---|
To: | Andreas Kretschmer <andreas(at)a-kretschmer(dot)de>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
Subject: | RE: simple query running long time within a long transaction. |
Date: | 2023-11-18 11:13:50 |
Message-ID: | PH0PR11MB51914C1C04B816D1865BCDC7D6B6A@PH0PR11MB5191.namprd11.prod.outlook.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Looks like it's not sql issue, manually running still use prepared statements and use same sql plan.
-----Original Message-----
From: Andreas Kretschmer <andreas(at)a-kretschmer(dot)de>
Sent: Friday, November 17, 2023 5:17 PM
To: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: simple query running long time within a long transaction.
Am 17.11.23 um 09:10 schrieb James Pang (chaolpan):
>
> Hi,
>
> We found one simple query manually run very fast(finished in
> several milliseconds), but there are 2 sessions within long
> transaction to run same sql with same bind variables took tens of seconds.
>
you try to set plan_cache_mode to force_custom_plan, default is auto and with that and bind variables pg will use a generic plan.
Regards, Andreas
--
Andreas Kretschmer - currently still (garden leave)
Technical Account Manager (TAM)
www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Gulp | 2023-11-18 11:18:44 | |
Previous Message | Andreas Kretschmer | 2023-11-17 09:17:18 | Re: simple query running long time within a long transaction. |