Good catch Jeff.
as for which version. We always recommend the latest version. 42.1.4
On 29 September 2017 at 06:44, Subramaniam C <subramaniam31784@xxxxxxxxx> 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 <jeff.janes@xxxxxxxxx> wrote:On Thu, Sep 28, 2017 at 2:59 AM, Subramaniam C <subramaniam31784@xxxxxxxxx> 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
