agora inbox for pgsql-admin@postgresql.org
help / color / mirror / Atom feedFrom: Phani Prathyush Somayajula <phani.somayajula@pragmaticplay.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
To: pgsql-admin@lists.postgresql.org <pgsql-admin@lists.postgresql.org>
Subject: RE: Postgres RDS DB Parameters ::INSTANCE CLASS : db.m6id.2xlarge
Date: Tue, 18 Jun 2024 12:10:02 +0000
Message-ID: <AS4PR10MB55453B71CDBE29FAE75645478DCE2@AS4PR10MB5545.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <e724e250c37c61ce3ac33eeb734e6c3f25f6db89.camel@cybertec.at>
References: <MAXPR01MB3328F773227E6C76B06CF21BFC22A@MAXPR01MB3328.INDPRD01.PROD.OUTLOOK.COM>
<AS4PR10MB55453EC83E81241722755F8E8D0E2@AS4PR10MB5545.EURPRD10.PROD.OUTLOOK.COM>
<AS4PR10MB55452ECA456BF214261EB8398DCE2@AS4PR10MB5545.EURPRD10.PROD.OUTLOOK.COM>
<e724e250c37c61ce3ac33eeb734e6c3f25f6db89.camel@cybertec.at>
Hello @Laurenz,
Thank you for your quick response. However, the parameters are already in place as you said. Although, there is no issue with the update statement. The Execution Plan and the usage of index is optimal for the query. I just want to verify if any connection pooling is required from database side
Regards,
Phani
-----Original Message-----
From: Laurenz Albe <laurenz.albe@cybertec.at>
Sent: Tuesday, June 18, 2024 5:11 PM
To: Phani Prathyush Somayajula <phani.somayajula@pragmaticplay.com>; pgsql-admin@lists.postgresql.org
Subject: Re: Postgres RDS DB Parameters ::INSTANCE CLASS : db.m6id.2xlarge
On Tue, 2024-06-18 at 10:38 +0000, Phani Prathyush Somayajula wrote:
> I have an AWS RDS instance
>
> We are seeing a lot of CPU consumption where we’re load testing our application.
> The query which is taking a lot of time is running less than 1ms if I
> run through my psql client on the server and is taking 162ms if I run it from dBeaver.
>
> I just want to analyse if the parameters that I set are optimal to the application or not.
I don't think that twiddling the parameters will make a lot of difference there.
The exception could be if you are retrieving results with a cursor; then setting "cursor_tuple_fraction" to 1 could make a difference.
Other than that, you should use auto_explain with "auto_explain.log_analyze = on"
and "auto_explain.log_buffers = on" to capture an execution plan from the slow execution with DBeaver or your application. Examining that plan should show what is going on.
Yours,
Laurenz Albe
view thread (5+ messages) latest in thread
Message-ID: <AS4PR10MB55453B71CDBE29FAE75645478DCE2@AS4PR10MB5545.EURPRD10.PROD.OUTLOOK.COM>
Permalink: ../AS4PR10MB55453B71CDBE29FAE75645478DCE2@AS4PR10MB5545.EURPRD10.PROD.OUTLOOK.COM/
Also on: postgresql.org/message-id/AS4PR10MB55453B71CDBE29FAE75645478DCE2@AS4PR10MB5545.EURPRD10.PROD.OUTLOOK.COM
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: pgsql-admin@postgresql.org
Cc: phani.somayajula@pragmaticplay.com, laurenz.albe@cybertec.at, pgsql-admin@lists.postgresql.org
Subject: RE: Postgres RDS DB Parameters ::INSTANCE CLASS : db.m6id.2xlarge
In-Reply-To: <AS4PR10MB55453B71CDBE29FAE75645478DCE2@AS4PR10MB5545.EURPRD10.PROD.OUTLOOK.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