Задать вопрос
des1roer
@des1roer
ученье - свет, а неученье - приятный полумрак
postgresql

Постгрес оптимизация запроса?

PostgreSQL 9.3.3 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4), 64-bit
/------ 04.02.2015 8:40:12 --------/

EXPLAIN ANALYZE SELECT EXTRACT(EPOCH FROM "F_Date"), "F_ConvertedValue", "F_TagName_ID" FROM "SC_Tag"."T_TagData" where "F_Date" > (localtimestamp - interval'1 hour') and "F_TagName_ID" in (73,72,39,64,76,75)

            ORDER BY "F_Date" asc;;

/* Результат : "LOG: duration: 11276.442 ms statement: EXPLAIN ANALYZE SELECT EXTRACT(EPOCH FROM "F_Date"), "F_ConvertedValue", "F_TagName_ID" FROM "SC_Tag"."T_TagData" where "F_Date" > (localtimestamp - interval'1 hour') and "F_TagName_ID" in (73,72,39,64,76,75) ORDER BY "F_Date" asc;;

возвращено записей: 7 (выполнено: 11,279 с; всего: 11,279 с)" */

/------ 04.02.2015 8:49:52 --------/

EXPLAIN ANALYZE SELECT EXTRACT(EPOCH FROM "F_Date"), "F_ConvertedValue", "F_TagName_ID" FROM "SC_Tag"."T_TagData" where "F_Date" > (localtimestamp - interval'1 hour') and "F_TagName_ID" in (73,72,39,64,76,75)

            --ORDER BY "F_Date" asc;;

/* Результат : "LOG: duration: 9359.324 ms statement: EXPLAIN ANALYZE SELECT EXTRACT(EPOCH FROM "F_Date"), "F_ConvertedValue", "F_TagName_ID" FROM "SC_Tag"."T_TagData" where "F_Date" > (localtimestamp - interval'1 hour') and "F_TagName_ID" in (73,72,39,64,76,75)

возвращено записей: 4 (выполнено: 9,360 с; всего: 9,375 с)" */

iscdUlw.pngW1fTw5q.png

это вообще кошмарно. может имеет смысл сортировать уже на клиенте али может какие другие соображения будут?
  • Вопрос задан
  • 2555 просмотров
Комментировать
Подписаться 2 Оценить Комментировать
Решения вопроса 1
DmitriyEntelis
@DmitriyEntelis
Думаю за деньги
des1roer: CREATE INDEX насколько понимаю создает индексы для наиболее часто используемых данных. но если данные динамические то как это сделать и поможет ли

des1roer: Вы понимаете не правильно.

1) индекс нужен для ускорения поиска и сортировки

2) без "order by" порядок кортежей вообще не гарантирован.
даже с "order by" если у нескольких кортежей совпадают значения в поле по которому идет сортировка - их порядок не гарантирован.
индекс по (F_Date,F_TagName_ID) существенно ускорит выборку я полагаю

3)В порядке бреда: т.к в таблице у Вас весьма много записей - есть смысл обдумать так ли их надо хранить в реляционной базе, или можно агрегировать в списки например по часам и класть в какую нибудь монгу? Ну или хотя бы чистить старые записи. Или переносить их в другую таблицу.
Ответ написан
2 комментария
2 комментария
Пригласить эксперта
Ответы на вопрос 1
@krypt3r
Начните с CREATE INDEX
Ответ написан
5 комментариев
5 комментариев
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Вакансии с Хабр Карьеры
Разработчик баз данных PostgreSQL
Объединенные системы управления транспортом • Москва
До 220 000 ₽
Администратор PostgreSQL
Гринатом
До 200 000 ₽
DBA / Администратор баз данных PostgreSQL
СберТех • Москва
от 320 000 ₽
Ещё вакансии
Заказы с Хабр Фриланса
Завершение разработки проекта на CS2
25 апр. 2024, в 20:02
100000 руб./за проект
Требуется завершить backend (проектная работа)
25 апр. 2024, в 19:42
49000 руб./за проект
Проверить тест по Data Science
25 апр. 2024, в 19:41
2000 руб./за проект
Ещё заказы