История изменений

Вообще не представляю, почему оно выбирает индекс по дате, если в конечном счёте вас интересуют айдишники.

Второй план действительно выливается в голимый SeqScan по дереву… Явно ещё и напрягая диск своими обращениями.

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

Может, статистика думает, что вы со своим запросом получите очень много строк и их придётся мучительно сортировать? Или о чем оно может ещё думать…

Может статистика слишком мала, или обновляется слишком редко? Или может она права и у вас в БД где-то присутствуют вот такие страшные крайние случаи.

Я это на кофейной гуще гадаю, опыта работы со столь большими БД у меня не было.

Вижу пару идей для решения:

0. Пошаманить над статистикой

1. Составной индекс по tab1(some_id, some_date). Но как бы не знаю. Может оно и его проигнорирует. 😃 Да и у вас БД большая, не знаю, насколько можете себе позволить вкорячивать ещё индексов, особенно, если оно сильно и не нужно.

2. Если вы уверены, что одинаковых some_id всегда относительно немного, то почему бы просто не вынести выборку по some_id в подзапрос или временную таблицу, а отсортировать/отлимитить уже снаружи? Возможно, так ему использовать idx_tab_some_id покажется более привлекательным.

Судя по последнему вашему сообщению, вы именно так (п.2) и сделали?

Вообще не представляю, почему оно выбирает индекс по дате, если в конечном счёте вас интересуют айдишники.

Второй план действительно выливается в голимый SeqScan по дереву… Явно ещё и напрягая диск своими обращениями.

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

Может, статистика думает, что вы со своим запросом получите очень много строк и их придётся мучительно сортировать? Или о чем оно может ещё думать…

Может статистика слишком мала, или обновляется слишком редко? Или может она права и у вас в БД где-то присутствуют вот такие страшные крайние случаи.

Я это на кофейной гуще гадаю, опыта работы со столь большими БД у меня не было.

Вижу пару идей для решения: 0. Пошаманить над статистикой

1. Составной индекс по tab1(some_id, some_date). Но как бы не знаю. Может оно и его проигнорирует. 😃 Да и у вас БД большая, не знаю, насколько можете себе позволить вкорячивать ещё индексов, особенно, если оно сильно и не нужно.

2. Если вы уверены, что одинаковых some_id всегда относительно немного, то почему бы просто не вынести выборку по some_id в подзапрос или временную таблицу, а отсортировать/отлимитить уже снаружи? Возможно, так ему использовать idx_tab_some_id покажется более привлекательным.

Судя по последнему вашему сообщению, вы именно так (п.2) и сделали?

Вообще не представляю, почему оно выбирает индекс по дате, если в конечном счёте вас интересуют айдишники.

Второй план действительно выливается в голимый SeqScan по дереву… Явно ещё и напрягая диск своими обращениями.

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

Может, статистика думает, что вы со своим запросом получите очень много строк и их придётся мучительно сортировать? Или о чем оно может ещё думать…

Может статистика слишком мала, или обновляется слишком редко? Или может она права и у вас в БД где-то присутствуют вот такие страшные крайние случаи.

Я это на кофейной гуще гадаю, опыта работы со столь большими БД у меня не было.

Вижу пару идей для решения: 0. Пошаманить над статистикой

1. Составной индекс по tab1(some_id, some_date). Но как бы не знаю. Может оно и его проигнорирует. 😃 Да и у вас БД большая, не знаю, насколько можете себе позволить вкорячивать ещё индексов, особенно, если оно сильно и не нужно. 2.Если вы уверены, что одинаковых some_id всегда относительно немного, то почему бы просто не вынести выборку по some_id в подзапрос или временную таблицу, а отсортировать/отлимитить уже снаружи? Возможно, так ему использовать idx_tab_some_id покажется более привлекательным.

Судя по последнему вашему сообщению, вы именно так (п.2) и сделали?