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 <jeff.ja...@gmail.com> wrote:
> On Thu, Sep 28, 2017 at 2:59 AM, Subramaniam C <subramaniam31...@gmail.com
> > 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
>
