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 >