public inbox for [email protected]
help / color / mirror / Atom feedFrom: Dave Cramer <[email protected]>
To: Subramaniam C <[email protected]>
Cc: Jeff Janes <[email protected]>
Cc: Pavy Philippe <[email protected]>
Cc: Julien Rouhaud <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: Slow query in JDBC
Date: Fri, 29 Sep 2017 09:04:46 -0400
Message-ID: <CADK3HH+68Swe-takYvrk++3T_gsUBeMUoVOntuM13HWuoyrOOQ@mail.gmail.com> (raw)
In-Reply-To: <CAL=06W=NSLTJmDAuUo+425vTbK+oA4ER+AgDHCHdvndZcbE+8A@mail.gmail.com>
References: <CAL=06W=f17ZnNQ8AdUKpd0p-6dfdwLios-Pvqkhqm7L8ziopjQ@mail.gmail.com>
<CAOBaU_bDpYP-G0uA4Rbdv6DgToEGgkMvufftxxzAJWWcxoCKfg@mail.gmail.com>
<CAL=06Wme9NwYw9nDv034_DUJdzRxoDpK3r0v48-8fn-y=q+yyA@mail.gmail.com>
<CAOBaU_beQv5GoeaZT3Jk382MtsfTfMUmXaN9cS_ocunw4UKqxA@mail.gmail.com>
<5F8F324242D0E14B97060D4D32CD0F5C014910CA886C@FRSPX100.fr01.awl.atosorigin.net>
<CAL=06WmGpUq=GEM9tYpbjATYObge0rV9P+sycKh7-bCX3gWQ1w@mail.gmail.com>
<CAMkU=1wHLUx19hBkvWVgppo0Dk=HVHm7wU9Tfsx5Y_jRSkV-Hw@mail.gmail.com>
<CAL=06W=NSLTJmDAuUo+425vTbK+oA4ER+AgDHCHdvndZcbE+8A@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-performance>
Good catch Jeff.
as for which version. We always recommend the latest version. 42.1.4
Dave Cramer
[email protected]
www.postgresintl.com
On 29 September 2017 at 06:44, Subramaniam C <[email protected]>
wrote:
> Yes you are right the timestamp which the application was providing was in
> seconds whereas the query which was using index had a timestamp in
> milliseconds. So the query was taking time in application.
>
> On Fri, Sep 29, 2017 at 12:19 PM, Jeff Janes <[email protected]> wrote:
>
>> On Thu, Sep 28, 2017 at 2:59 AM, Subramaniam C <
>> [email protected]> 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. AS
>>> per the output it is clear that the when the query is executed through JDBC
>>> 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.)
>>>
>>>
>>> * -> Index Only Scan
>>> using health_index on health_timeseries_table (cost=0.56..421644.56
>>> rows=1558800 width=24)*
>>>
>>> * Index Cond: (("timestamp" >=
>>> '1505989186834'::bigint) AND ("timestamp" <= '1505990086834'::bigint))*
>>>
>>>
>>
>>> 2.)
>>>
>>>
>>> -> Seq Scan on
>>> health_timeseries_table (cost=0.00..267171.00 rows=1005634 width=24)
>>>
>>> Filter: (("timestamp" >=
>>> '1505989500000'::bigint) AND ("timestamp" <= '1505990400000'::bigint))
>>>
>>
>>
>> Those are different queries, so it is not terribly surprising it might
>> choose a different plan.
>>
>> For this type of comparison, you need to compare identical queries,
>> including parameter.
>>
>> Cheers,
>>
>> Jeff
>>
>
>
view thread (13+ messages)
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: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Slow query in JDBC
In-Reply-To: <CADK3HH+68Swe-takYvrk++3T_gsUBeMUoVOntuM13HWuoyrOOQ@mail.gmail.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