2014-12-18 1 views
4

Я выполняю много запросов sql следующим образом. Представьте, что у нас есть база данных с рейсами, где каждый рейс может иметь исходящий и входящий аэропорт, конечно, дату вылета, количество остановок между проездом и пунктом назначения (на длинных рейсах) и, конечно, цена.Как уменьшить затраты на выбор sql по заказу?

Теперь я хочу выбрать конкретный маршрут и выбрать тот, который имеет наименьшее количество остановок и, конечно же, лучший из них.

CREATE TABLE flights(
    id integer 
    outbound character varying, 
    inbound character varying, 
    date timestamp, 
    stops integer 
    price numeric 
); 
CREATE INDEX my_idx ON flights (outbound, inbound, date, stops, price); 

select * from flights where outbound = 'SFO' and inbound = 'SYD' and date = '2015-10-10' and stops < 2 order by stops asc, price asc. 

Проблема: затраты с использованием explain-analyze довольно высоки:

Sort (cost=9.78..9.79 rows=1 width=129) (actual time=0.055..0.055 rows=4 loops=1) 
    Sort Key: stops, price 
    Sort Method: quicksort Memory: 26kB 
    -> Index Scan using my_idx (cost=0.42..9.77 rows=1 width=129) (actual time=0.039..0.041 rows=4 loops=1) 
     Index Cond: ((date = '2015-10-10'::date) AND ((outbound)::text = 'SFO'::text) AND (stops < 2) AND ((inbound)::text = 'SYD'::text)) 
Total runtime: 0.079 ms 

Если я просто сортировать по цене без остановок, расходы в порядке (0,42). Но сортировка по остановкам как-то увеличивает стоимость значительным.

Как я могу сократить расходы?

postgresql 9.3.2

+0

Ваша версия Postgres имеет решающее значение (и всегда должна быть в вопросе). –

+0

'postgresql 9.3.2'е, обновленный выше – membersound

+0

Err ... Ориентировочная стоимость на самом деле крошечная. '0.42..9.77' ->' 9.78..9.79'. Что дорого стоит в поиске строк. Вы уверены, что вам следует беспокоиться о стоимости сортировки * четырех строк? :-) –

ответ

5

Судя по заданным номерам, ваш альтернативный запрос («Если бы я просто сортировать по цене без остановок») на самом деле медленнее, и вы неправильно цифры. 0.079 ms - 0.42 (?).

Это также имеет смысл, потому что ваш первый запрос отлично соответствует порядку сортировки индекса.

У вас уже есть идеальный индекс. Предложение об исключении price является необоснованным. Дополнительный столбец удаляет затраты для этапа сортировки: time=0.055..0.055, как вы можете видеть в плане.

В любом случае, это не имеет большого значения. Как только вы уменьшите количество строк, полученных на , небольшое число (с предикатами на ведущих столбцах индекса), остальное дешево в любом случае.

Чтобы получить более интересные результаты, не проверяйте stops < 2 (который оставляет только 0 и 1 остановку), попробуйте с большим числом, чтобы увидеть любую (возможно маленькую) разницу.

На самом деле, так как почти все столбцы в индексе уже, я хотел бы попробовать и добавить один столбец id отсутствует, тоже - если вы можете получить index-only scans из этого (Postgres 9.2+, читать Postgres Wiki на связанной странице):

CREATE INDEX my_idx ON flights (outbound, inbound, date, stops, price, id);
SELECT id, outbound, inbound, date, stops, price 
FROM ... 
2

Это ваш запрос:

select * 
from flights 
where outbound = 'SFO' and inbound = 'SYD' and date = '2015-10-10' and stops < 2 
order by stops asc, price asc. 

Оптимальный индекс: flights(outbound, inbound, date, stops). Это относится к статье where. Я не знаю, есть ли способ устранить order by, учитывая where, но сортировка не должна быть большой проблемой, если в этот день не будет тысяч рейсов.

+0

Может быть, мне даже не нужен индекс здесь? Разница без индексов индексирования составляет 0,006 мс. Если вы считаете, что в этом случае индекс из 3 вместо 4 столбцов больше выгоден? – membersound

+1

@membersound. , , 'stop', вероятно, имеет минимальное влияние, в зависимости от количества процедур, которые имеют более одной остановки. Но я бы включил его, потому что дополнительный столбец в индексе не слишком много накладных расходов. –

0

затраты произвольная фигура.

Кроме того, показатели для стадии сортировки являются суммарные совокупные затраты в плане при входе и выходе на этот шаг, а не конкретных расходов, связанных с этим индивидуальным шагом.

Ваш запрос выполняется быстро. Это всего четыре строки, и он завершает весь запрос в 0.079 мс.

Смежные вопросы