72279818787780
Planning Time: 0.062 ms
Execution Time: 5049.131 ms
Thanks,
Hassan
On Mon, Mar 11, 2024 at 12:00 PM hassan rafi
wrote:
> Thanks all. Will try upgrading the postgres version.
>
> On Sun, Mar 10, 2024 at 11:44 PM Ron Johnson
> wrote:
>
>> On Sun, Mar 10, 2024
Thanks all. Will try upgrading the postgres version.
On Sun, Mar 10, 2024 at 11:44 PM Ron Johnson
wrote:
> On Sun, Mar 10, 2024 at 1:34 PM Greg Sabino Mullane
> wrote:
>
>>
>> On Sat, Mar 9, 2024 at 1:57 PM hassan rafi
>> wrote:
>>
>>> Would u
Thanks,
Would upgrading to the latest version of Postgres potentially solve the
issue?
On Sat, Mar 9, 2024 at 11:30 PM Tom Lane wrote:
> hassan rafi writes:
> > The issue of high query planning time seems to intermittently resolve
> > itself, only to reoccur after a few hours.
the latest release of said EOL
> version. And if I am not mistaken, "Azure Postgres single server
> version" is also deprecated, so you should really focus on getting
> upgraded to something more modern.
>
> Robert Treat
> https://xzilla.net
>
> On Sat, Mar 9, 2024
|
++-+-+---++--+--+-+
products_inventory_delta| 2847202|259351648| 1606201|r |
4|false |NULL | 23330758656|
Peak load (write): 3000 TPS (mostly updates).
Peak load (read): 800 TPS.
On Sat, Mar 9, 2024 at 5:58 PM Ron Johnson wrote:
> On Sat, Mar 9, 2024 at 7:18 AM has
Hi team,
We are seeing unusually high query planning times on our Postgres server. I
am attaching a few query plans.
select upc from store_seller_products where upc in
('0001600015840','0001600015781','0001600015777','0001600015765','0001600015764','0001600015762','0001600015483','0001600015163',
