Re: limit order by performance issue - Mailing list pgsql-performance

From Claudio Freire
Subject Re: limit order by performance issue
Date
Msg-id CAGTBQpZn6DvCDkdBr1bmW_cO1sm=mpd8mkniy7bOVfrti=qDQA@mail.gmail.com
Whole thread Raw
In response to Re: limit order by performance issue  (Pedro Jiménez Pérez <p.jimenez@ismsolar.com>)
List pgsql-performance


On Wed, Oct 17, 2012 at 6:14 AM, Pedro Jiménez Pérez <p.jimenez@ismsolar.com> wrote:
select var_value from ism_floatvalues where id_signal = 29660 order by time_stamp desc limit 1;

This is what EXPLAIN returns (can't make EXPLAIN ANALYZE because it "never" ends):

"Limit  (cost=0.00..258.58 rows=1 width=16)"
"  ->  Index Scan Backward using ism_floatvalues_index_time_stamp on ism_floatvalues  (cost=0.00..8912076.82 rows=34466 width=16)"
"        Filter: (id_signal = 29660)"

This is EXPLAIN ANALYZE without "limit 1":

Add (or modify the existing) an index on id_signal, time_stamp desc, and you're done.

It must be a case of descending time stamps not hitting the filter condition (id_signal) soon enough.

pgsql-performance by date:

Previous
From: Shaun Thomas
Date:
Subject: Re: How to upgrade from 9.1 to 9.2 with replication?
Next
From: Thomas Kellerer
Date:
Subject: Re: Recursive query gets slower when adding an index