I have a big table (~44 GB, 421631931 rows) .
I'm attempting to optimize this type of SQL query:
SELECT fid, sid, dsc_entry, clstr_first_entry, date_part('epoch',start_time)::numeric(20,7) AS time_epoch
FROM frames
WHERE (sid = 1)
AND start_time <= to_timestamp('1471161210.776')
ORDER BY start_time DESC
LIMIT 1;
So far, I have set up index on the column start_time
:
"idx_start_time" btree (start_time) CLUSTER
When I run EXPLAIN
, I get this plan:
Limit (cost=0.57..0.92 rows=1 width=24)
-> Index Scan Backward using idx_start_time on frames (cost=0.57..19347837.35 rows=55108378 width=24)
Index Cond: (start_time <= '2016-08-14 09:53:30.776+02'::timestamp with time zone)
Filter: (sid = 1)
This looks good to me (note that I have never attempted to optimize databases this way before), but the query still takes about approximately 80 seconds to complete.
Can you please point out to me, how can I speed this up some more? (disk space is not an issue)
Thanks, Petr.
For this query:
SELECT fid, sid, dsc_entry, clstr_first_entry,
date_part('epoch', start_time)::numeric(20,7) AS time_epoch
FROM frames
WHERE (sid = 1) AND start_time <= to_timestamp('1471161210.776')
ORDER BY start_time DESC
LIMIT 1;
I would recommend an index on frames(sid, start_time)
.
the problem is the order by, because is the inverse of the index. Try using:
CREATE INDEX ix ON frames (start_time DESC NULLS LAST);
The order by desc requieres an additional time to resort the data in a temp table.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.