Postgres Pro
Downloads
Home   >   mailing lists

Re: select performance. - Mailing list pgsql-admin

From Dhandapani Shanmugam
Subject Re: select performance.
Date
Msg-id CAAj4MFEsjrD4+vJdv+3BETYN+rmGRN8iQdFm_oj+e5TbT+6SVg@mail.gmail.com
Whole thread Raw
In response to Re: select performance.  (Fabio Pardi <f.pardi@portavita.eu>)
Responses Re: select performance.
List pgsql-admin
Tree view

Thanks for your response Fabio. 

>>
Since the select queries has $ parameters, I could not able to do the EXPLAIN ANALYZE  on that for example the select query is like below.

SELECT ... in ($3, $4, $5, $6)

>> PostgreSQL version 10, runs in CENTOS 7.2 with 64 GB of RAM. The table has only "character varying" and "numeric" as data type


-Dhandapani.

On Fri, Aug 10, 2018 at 2:05 PM, Fabio Pardi <f.pardi@portavita.eu> wrote:
Hi Dhandapani,

first of all, I do not think is a good idea to measure the response time
from the frontend. Run the query on the database and time it.

Also an EXPLAIN ANALYZE of the query will give you hints on what is
going on. Please post that too.

Additionally, you could tell us a bit more about your tables structure,
the data in it, the machine it runs on, your OS, your Postgres version
and how Postgres is configured.

This said, if your data resides in memory, data retrieval will indeed be
faster, but is not a 5 minutes job, using a silver bullet. It requires
analysis.

Let us know more, and we can probably tell you more.

regards,

fabio pardi



On 08/10/2018 10:12 AM, Dhandapani Shanmugam wrote:
> Hi All,
>
> My application does select with were condition using IN function on only
> one table and I see slow response from front end. Please clarify me, do
> we have options like memory tables or is it possible to pin entire table
> in memory or do we have any option to improve only select statement.
>
> -Dhandapani


pgsql-admin by date:

Previous
From: Fabio Pardi
Date:
Subject: Re: select performance.
Next
From: amit tripathi
Date:
Subject: Point in Time recovery on PostgreSQL (10.3.1)