From 3e582308131a99965435360cbc0706f6c9e83bcd Mon Sep 17 00:00:00 2001 From: Scott Lamb Date: Sat, 7 Jan 2017 00:16:34 -0800 Subject: [PATCH] avoid a SQLite3 sort in list_recordings_by_time This fixes a minor performance regression for recording lists introduced in eee887b by ordering by the start_time_90k (the natural order of the recording_cover index) rather than the composite_id (which requires a sort pass). "explain query plan" before: 0|0|0|SEARCH TABLE recording USING INDEX recording_cover (start_time_90k>? AND start_time_90k? AND start_time_90k(&self, camera_id: i32, desired_time: Range, f: F) -> Result<(), Error> where F: FnMut(ListRecordingsRow) -> Result<(), Error> { @@ -796,6 +796,7 @@ impl LockedDatabase { self.list_recordings_inner(camera_id, rows, f) } + /// Lists the specified recordigs in ascending order by id. pub fn list_recordings_by_id(&self, camera_id: i32, desired_ids: Range, f: F) -> Result<(), Error> where F: FnMut(ListRecordingsRow) -> Result<(), Error> { @@ -1132,7 +1133,7 @@ impl Database { recording.start_time_90k < :end_time_90k and recording.start_time_90k + recording.duration_90k > :start_time_90k order by - recording.composite_id + recording.start_time_90k "#, recording::MAX_RECORDING_DURATION); { use std::error::Error as E;