Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dxbkI-0007Ia-9N for pgsql-performance@arkaria.postgresql.org; Thu, 28 Sep 2017 16:33:06 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dxbkH-0006bc-JG for pgsql-performance@arkaria.postgresql.org; Thu, 28 Sep 2017 16:33:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dxbkH-0006bT-1q for pgsql-performance@postgresql.org; Thu, 28 Sep 2017 16:33:05 +0000 Received: from mail-wr0-x244.google.com ([2a00:1450:400c:c0c::244]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dxbkD-0005lv-7I for pgsql-performance@postgresql.org; Thu, 28 Sep 2017 16:33:04 +0000 Received: by mail-wr0-x244.google.com with SMTP id p37so2554391wrb.5 for ; Thu, 28 Sep 2017 09:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZTNlLzOSqYHPEkmDTsYLkebW1WBqsWkBvEu4GOjKBW8=; b=lbnfybPPGLY7BLLQA/mXeRWkeWUrRjiJ41f09PSfFITD1JFWZ76k5EOEgAUK24JMkf QIxq4Flkc0D0a7et79ZAnIcYQYqQAZK+FXvxrZcp6taqG9ubEZQKf2Wn+OQtNHzsfFdM P35znKQyxQVKQs9xA6Q+LGHtgOz7/s5ydF3TV2kjJxCeiUSpn0aGC/rlNB1QFv15cvCe RvKLUgDnoXJ1yb/Q+iPyVyO8LtggdUCtcxuiBE6KAxw5CETKtN3k8v4lxWhRvZ1HtwOi SwZNlKOjNGgD2P6e+jDF/cT7CKd0bzynLyhd0Rt8nifJPIfq/i6PB3xmSKXHQIwWCqLd mVVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZTNlLzOSqYHPEkmDTsYLkebW1WBqsWkBvEu4GOjKBW8=; b=L00PfeRdKvl16iY5JvVG850/l0zErEGkiHwBB5orPD3zJuxhe0mG7Q7q+/msKGAqCZ q4F3z1Q3yvPX4A+I3v8HGy7BgzE+vVPVO+1yj+Tngh/xFYFdxZe669ysSARP5RgRLRFX KrB59zlyz3dpcVjsBgJf5m26FqY4QvKIQ2c0LlyaJTC/UBuy0P+rDhJIiWjpK47gHAzL /UGr9zHokMZUIaZQRDCjsy/vPAPO+ECLRXXkEKXZQDOJiVu48uXvqcKWqS37+JyAqDso Y5EsI7opI15ArgDL/20/nuM/9JG8s0uPS9m4CH9DF+BX3/Qr9YpXYguHVfD/x39JArKV dZLA== X-Gm-Message-State: AHPjjUi0wjY2xGiiWTQr3YFZGHsdYZV+f6D3eCyGxPjYNEak4hkAIRMI N+nLLO8gSFNsxi/GBtLhjfgAwL9WYsEWH5yVAAg= X-Google-Smtp-Source: AOwi7QAHiOr/8fjApNmpAX6aSAJ+/zbi+c3G2KKAuz2ZBcv+fA04RASJCGXvn/FaKHy0UpYgEhxMuHGwHL2XkoROOlk= X-Received: by 10.46.99.201 with SMTP id s70mr2344645lje.143.1506616378576; Thu, 28 Sep 2017 09:32:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.235.85 with HTTP; Thu, 28 Sep 2017 09:32:58 -0700 (PDT) In-Reply-To: References: <5F8F324242D0E14B97060D4D32CD0F5C014910CA886C@FRSPX100.fr01.awl.atosorigin.net> From: Subramaniam C Date: Thu, 28 Sep 2017 22:02:58 +0530 Message-ID: Subject: Re: Slow query in JDBC To: Dave Cramer Cc: Pavy Philippe , Julien Rouhaud , "pgsql-performance@postgresql.org" Content-Type: multipart/alternative; boundary="001a114cea680ed493055a42764f" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org --001a114cea680ed493055a42764f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The JDBC version is 9.4-1201-jdbc41. Query :- select count(*) OVER() AS count,uuid,availability,objectname,datasourcename,datasourcetype,objecttype= ,health from (select distinct on (health_timeseries_table.mobid) mobid, health_timeseries_table.health, health_timeseries_table.timestamp from health_timeseries_table where timestamp >=3D 1505989186834 and timestamp <= =3D 1505990086834 ORDER BY health_timeseries_table.mobid DESC, health_timeseries_table.timestamp DESC, health_timeseries_table.health ASC) t right join (SELECT DISTINCT ON (object_table.uuid) uuid, object_table.timestamp,object_table.availability,object_table.objectname,ob= ject_table.datasourcename,object_table.datasourcetype,object_table.objectty= pe FROM object_table where object_table.timestamp >=3D 0 and object_table.timestamp <=3D 1505990086834 and object_table.tenantid =3D 'perspica' ORDER BY object_table.uuid DESC, object_table.timestamp DESC)u on (t.mobid =3D u.uuid) order by health asc limit 20 offset 0; Please let us know any other details? Thanks and Regards Subramaniam On Thu, Sep 28, 2017 at 7:29 PM, Dave Cramer wrote: > What version of the driver are you using? > > The driver does not automatically use a cursor, but it does use prepared > statements which can be slower. > > > Can you provide the query and the jdbc query ? > > > > Dave Cramer > > davec@postgresintl.com > www.postgresintl.com > > On 28 September 2017 at 05:59, Subramaniam C > wrote: > >> First output show the output when the query is executed from sql command >> line. The second output show when it is executed from the application. A= S >> per the output it is clear that the when the query is executed through J= DBC >> its not using the index (health_index) instead its doing sequence scan. >> Please let us know how this issue can be resolved from JDBC? >> >> 1.) >> >> >> *Limit (cost=3D510711.53..510711.58 rows=3D20 width=3D72)* >> >> * -> Sort (cost=3D510711.53..511961.53 rows=3D500000 width=3D72)* >> >> * Sort Key: health_timeseries_table.health* >> >> * -> WindowAgg (cost=3D0.98..497406.71 rows=3D500000 width=3D7= 2)* >> >> * -> Merge Left Join (cost=3D0.98..491156.71 rows=3D5000= 00 >> width=3D64)* >> >> * Merge Cond: (object_table.uuid =3D >> health_timeseries_table.mobid)* >> >> * -> Unique (cost=3D0.42..57977.00 rows=3D500000 >> width=3D64)* >> >> * -> Index Scan Backward using >> object_table_pkey on object_table (cost=3D0.42..56727.00 rows=3D500000 >> width=3D64)* >> >> * Index Cond: (("timestamp" >=3D 0) AND >> ("timestamp" <=3D '1505990086834'::bigint))* >> >> * Filter: (tenantid =3D 'perspica'::text= )* >> >> * -> Materialize (cost=3D0.56..426235.64 rows=3D55= 526 >> width=3D16)* >> >> * -> Unique (cost=3D0.56..425541.56 rows=3D5= 5526 >> width=3D24)* >> >> * -> Index Only Scan >> using health_index on health_timeseries_table (cost=3D0.56..421644.56 >> rows=3D1558800 width=3D24)* >> >> * Index Cond: (("timestamp" >=3D >> '1505989186834'::bigint) AND ("timestamp" <=3D '1505990086834'::bigint))= * >> >> *LOG: duration: 1971.697 ms* >> >> >> >> >> >> 2.) >> >> >> Limit (cost=3D457629.21..457629.26 rows=3D20 width=3D72) >> >> -> Sort (cost=3D457629.21..458879.21 rows=3D500000 width=3D72) >> >> Sort Key: health_timeseries_table.health >> >> -> WindowAgg (cost=3D367431.49..444324.39 rows=3D500000 width= =3D72) >> >> -> Merge Left Join (cost=3D367431.49..438074.39 rows=3D5= 00000 >> width=3D64) >> >> Merge Cond: (object_table.uuid =3D >> health_timeseries_table.mobid) >> >> -> Unique (cost=3D0.42..57977.00 rows=3D500000 wid= th=3D64) >> >> -> Index Scan Backward using object_table_pke= y >> on object_table (cost=3D0.42..56727.00 rows=3D500000 width=3D64) >> >> Index Cond: (("timestamp" >=3D '0'::bigi= nt) >> AND ("timestamp" <=3D '1505990400000'::bigint)) >> >> Filter: (tenantid =3D 'perspica'::text) >> >> -> Materialize (cost=3D367431.07..373153.32 >> rows=3D55526 width=3D16) >> >> -> Unique (cost=3D367431.07..372459.24 >> rows=3D55526 width=3D24) >> >> -> Sort (cost=3D367431.07..369945.16 >> rows=3D1005634 width=3D24) >> >> Sort Key: >> health_timeseries_table.mobid DESC, health_timeseries_table."timestamp" >> DESC, health_timeseries_table.health >> >> -> Seq Scan on >> health_timeseries_table (cost=3D0.00..267171.00 rows=3D1005634 width=3D= 24) >> >> >> Filter: (("timestamp" >=3D >> '1505989500000'::bigint) AND ("timestamp" <=3D '1505990400000'::bigint)) >> >> On Thu, Sep 28, 2017 at 2:56 PM, Pavy Philippe < >> Philippe.Pavy@worldline.com> wrote: >> >>> https://www.postgresql.org/docs/current/static/auto-explain.html >>> >>> >>> -----Message d'origine----- >>> De : pgsql-performance-owner@postgresql.org [mailto: >>> pgsql-performance-owner@postgresql.org] De la part de Julien Rouhaud >>> Envoy=C3=A9 : jeudi 28 septembre 2017 11:21 >>> =C3=80 : Subramaniam C >>> Cc : pgsql-performance@postgresql.org >>> Objet : Re: [PERFORM] Slow query in JDBC >>> >>> On Thu, Sep 28, 2017 at 10:58 AM, Subramaniam C < >>> subramaniam31784@gmail.com> wrote: >>> > I configured cursor_tuple_fraction to 1 but still I am facing the sam= e >>> > issue. >>> >>> Can you show explain (analyze, buffers) of the query when run from psql >>> and run from application (you can use auto_explain for that if needed, = see >>> https://www.postgresql.org/docs/current/static/auto-explain.html). >>> >>> >>> -- >>> Sent via pgsql-performance mailing list (pgsql-performance@postgresql. >>> org) >>> To make changes to your subscription: >>> http://www.postgresql.org/mailpref/pgsql-performance >>> >>> !!!********************************************************* >>> **************************** >>> "Ce message et les pi=C3=A8ces jointes sont confidentiels et r=C3=A9ser= v=C3=A9s =C3=A0 >>> l'usage exclusif de ses destinataires. Il peut =C3=A9galement =C3=AAtre= prot=C3=A9g=C3=A9 par >>> le secret professionnel. Si vous recevez ce message par erreur, merci d= 'en >>> avertir imm=C3=A9diatement l'exp=C3=A9diteur et de le d=C3=A9truire. L'= int=C3=A9grit=C3=A9 du >>> message ne pouvant =C3=AAtre assur=C3=A9e sur Internet, la responsabili= t=C3=A9 de >>> Worldline ne pourra =C3=AAtre recherch=C3=A9e quant au contenu de ce me= ssage. Bien >>> que les meilleurs efforts soient faits pour maintenir cette transmissio= n >>> exempte de tout virus, l'exp=C3=A9diteur ne donne aucune garantie =C3= =A0 cet =C3=A9gard et >>> sa responsabilit=C3=A9 ne saurait =C3=AAtre recherch=C3=A9e pour tout d= ommage r=C3=A9sultant >>> d'un virus transmis. >>> >>> This e-mail and the documents attached are confidential and intended >>> solely for the addressee; it may also be privileged. If you receive thi= s >>> e-mail in error, please notify the sender immediately and destroy it. A= s >>> its integrity cannot be secured on the Internet, the Worldline liabilit= y >>> cannot be triggered for the message content. Although the sender endeav= ours >>> to maintain a computer virus-free network, the sender does not warrant = that >>> this transmission is virus-free and will not be liable for any damages >>> resulting from any virus transmitted.!!!" >>> >> >> > --001a114cea680ed493055a42764f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The JDBC version is=C2=A09.4-1201-jdbc41.

Query :-

select count(*) OVER() AS coun= t,uuid,availability,objectname,datasourcename,datasourcetype,objecttype,hea= lth from (select distinct on (health_timeseries_table.mobid) mobid, health_= timeseries_table.health, health_timeseries_table.timestamp from health_time= series_table where timestamp >=3D 1505989186834 and timestamp <=3D 15= 05990086834 ORDER BY health_timeseries_table.mobid DESC, health_timeseries_= table.timestamp DESC, health_timeseries_table.health ASC) t right join (SEL= ECT DISTINCT ON (object_table.uuid) uuid, object_table.timestamp,object_tab= le.availability,object_table.objectname,object_table.datasourcename,object_= table.datasourcetype,object_table.objecttype FROM object_table where=C2=A0 = object_table.timestamp >=3D 0 and object_table.timestamp <=3D 1505990= 086834 and object_table.tenantid =3D 'perspica' ORDER BY object_tab= le.uuid DESC, object_table.timestamp DESC)u on (t.mobid =3D u.uuid) order b= y health asc limit 20 offset 0;


Please let us = know any other details?


Thanks and Regards

Subramaniam


<= div class=3D"gmail_quote">On Thu, Sep 28, 2017 at 7:29 PM, Dave Cramer <pg@= fastcrypt.com> wrote:
What version of the driver are you using?

Th= e driver does not automatically use a cursor, but it does use prepared stat= ements which can be slower.


Can you= provide the query and the jdbc query ?


=


On 28 September 2017 at 05:59, Subramaniam C= <subramaniam31784@gmail.com> wrote:
First output show the output when the query is executed from sql c= ommand line. The second output show when it is executed from the applicatio= n. AS per the output it is clear that the when the query is executed throug= h JDBC its not using the index (health_index) instead its doing sequence sc= an. Please let us know how this issue can be resolved from JDBC?

1.)


<= i>Limit=C2=A0 (cost=3D510711.53..510711.58 rows=3D20 width=3D72)=

=C2=A0 ->=C2=A0 Sort=C2=A0 (cost=3D510711.53..511961.53 rows=3D500000= width=3D72)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sort Key: health_time= series_table.health

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 W= indowAgg=C2=A0 (cost=3D0.98..497406.71 rows=3D500000 width=3D72)=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Merge Left = Join=C2=A0 (cost=3D0.98..491156.71 rows=3D500000 width=3D64)

=

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Merge= Cond: (object_table.uuid =3D health_timeseries_table.mobid)

=

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->= =C2=A0 Unique=C2=A0 (cost=3D0.42..57977.00 rows=3D500000 width=3D64)

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Index Scan Backward using object_table= _pkey on object_table=C2=A0 (cost=3D0.42..56727.00 rows=3D500000 width=3D64= )

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Index Cond: (("ti= mestamp" >=3D 0) AND ("timestamp" <=3D '1505990086= 834'::bigint))

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filt= er: (tenantid =3D 'perspica'::text)

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Materializ= e=C2=A0 (cost=3D0.56..426235.64 rows=3D55526 width=3D16)

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ->=C2=A0 Unique=C2=A0 (cost=3D0.56..425541.56 rows=3D55526= width=3D24)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 = Index Only Scan using=C2=A0health_index=C2=A0on health_timeseries_ta= ble=C2=A0 (cost=3D0.56..421644.56 rows=3D1558800 width=3D24)

=

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Index Cond: ((&= quot;timestamp" >=3D '1505989186834'::bigint) AND ("ti= mestamp" <=3D '1505990086834'::bigint))

= LOG:=C2=A0 duration: 1971.697 ms





2.)


Limit=C2=A0 (cost=3D457629.21..= 457629.26 rows=3D20 width=3D72)

=C2=A0 ->=C2=A0 Sort=C2=A0 (cost=3D457629.= 21..458879.21 rows=3D500000 width=3D72)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Sort Key:= health_timeseries_table.health

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Windo= wAgg=C2=A0 (cost=3D367431.49..444324.39 rows=3D500000 width=3D72)

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Merge Left Join=C2=A0 (c= ost=3D367431.49..438074.39 rows=3D500000 width=3D64)

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Merge Cond: (object_table.uui= d =3D health_timeseries_table.mobid)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Unique=C2=A0 (cost=3D0.42..5797= 7.00 rows=3D500000 width=3D64)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Index Scan Backwa= rd using object_table_pkey on object_table=C2=A0 (cost=3D0.42..56727.00 row= s=3D500000 width=3D64)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Index Cond: ((&= quot;timestamp" >=3D '0'::bigint) AND ("timestamp"= ; <=3D '1505990400000'::bigint))

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Filter: (tenantid =3D 'perspica'::text)

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Materialize=C2= =A0 (cost=3D367431.07..373153.32 rows=3D55526 width=3D16)

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -= >=C2=A0 Unique=C2=A0 (cost=3D367431.07..372459.24 rows=3D55526 width=3D2= 4)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2=A0 Sort=C2=A0 (cost=3D36743= 1.07..369945.16 rows=3D1005634 width=3D24)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Sort Key: health_timeseries_table.mobid DESC, heal= th_timeseries_table."timestamp" DESC, health_timeseries_tabl= e.health

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ->=C2= =A0 Seq Scan on health_timeseries_table=C2=A0 (cost=3D0.00..267171.00 rows= =3D1005634 width=3D24)


<= span class=3D"m_2714955605295132182m_64864064281254455gmail-m_-866084349023= 9021530gmail-Apple-tab-span" style=3D"white-space:pre-wrap"> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 F= ilter: (("timestamp" >=3D '1505989500000'::bigint) AND= ("timestamp" <=3D '1505990400000'::bigint))

=

On T= hu, Sep 28, 2017 at 2:56 PM, Pavy Philippe <Philippe.Pavy@worldl= ine.com> wrote:
https://www.postgresql.org/docs/current/st= atic/auto-explain.html


-----Message d'origine-----
De : pgsql-performance-owner@postgresql.org [mailto:pgsql-perfor= mance-owner@postgresql.org] De la part de Julien Rouhaud
Envoy=C3=A9 : jeudi 28 septembre 2017 11:21
=C3=80 : Subramaniam C
Cc : = pgsql-performance@postgresql.org
Objet : Re: [PERFORM] Slow query in JDBC

On Thu, Sep 28, 2017 at 10:58 AM, Subramaniam C <subramaniam31784@gmail.com>= wrote:
> I configured cursor_tuple_fraction to 1 but still I am facing the same=
> issue.

Can you show explain (analyze, buffers) of the query when run from psql and= run from application (you can use auto_explain for that if needed, see https://www.postgresql.org/docs/cu= rrent/static/auto-explain.html).


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-pe= rformance

!!!**************************************************************= ***********************
"Ce message et les pi=C3=A8ces jointes sont confidentiels et r=C3=A9se= rv=C3=A9s =C3=A0 l'usage exclusif de ses destinataires. Il peut =C3=A9g= alement =C3=AAtre prot=C3=A9g=C3=A9 par le secret professionnel. Si vous re= cevez ce message par erreur, merci d'en avertir imm=C3=A9diatement l= 9;exp=C3=A9diteur et de le d=C3=A9truire. L'int=C3=A9grit=C3=A9 du mess= age ne pouvant =C3=AAtre assur=C3=A9e sur Internet, la responsabilit=C3=A9 = de Worldline ne pourra =C3=AAtre recherch=C3=A9e quant au contenu de ce mes= sage. Bien que les meilleurs efforts soient faits pour maintenir cette tran= smission exempte de tout virus, l'exp=C3=A9diteur ne donne aucune garan= tie =C3=A0 cet =C3=A9gard et sa responsabilit=C3=A9 ne saurait =C3=AAtre re= cherch=C3=A9e pour tout dommage r=C3=A9sultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely= for the addressee; it may also be privileged. If you receive this e-mail i= n error, please notify the sender immediately and destroy it. As its integr= ity cannot be secured on the Internet, the Worldline liability cannot be tr= iggered for the message content. Although the sender endeavours to maintain= a computer virus-free network, the sender does not warrant that this trans= mission is virus-free and will not be liable for any damages resulting from= any virus transmitted.!!!"



--001a114cea680ed493055a42764f--