简体   繁体   中英

SQL performance tuning with EXPLAIN

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.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM