Re: select performance.

Поиск
Список
Период
Сортировка
От Dhandapani Shanmugam
Тема Re: select performance.
Дата
Msg-id CAAj4MFEsjrD4+vJdv+3BETYN+rmGRN8iQdFm_oj+e5TbT+6SVg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: select performance.  (Fabio Pardi <f.pardi@portavita.eu>)
Ответы Re: select performance.  (Fabio Pardi <f.pardi@portavita.eu>)
Список pgsql-admin

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 по дате отправления:

Предыдущее
От: Fabio Pardi
Дата:
Сообщение: Re: select performance.
Следующее
От: amit tripathi
Дата:
Сообщение: Point in Time recovery on PostgreSQL (10.3.1)