Должен ли одинаковый запрос выполнятся с разным временем?

Question

[revukvr]

Здравствуйте! Столкнулся с такой проблемой. Есть 2 базы которые расположены на одном сервере. Одна релизная, а вторая для тестов. В релизной БД хранятся данные за 10 дней и там есть N количество данных. В тестовой базе хранятся данные за 5 дней и там есть примерно N/2 количество данных. В тестовой БД абсолютно идентичные данные за последние 5 дней релизной БД.

В чём собственно вопрос. Я хочу выбрать данные за отдельный день (например за сегодня), но когда я делаю запрос к релизной БД, то данные возвращаются мне за 8 секунд, А когда делаю запрос на тестовую БД, то данные возвращаются за 5-6 секунд. Правильно ли это? Я думал что запрос должен отсечь все данные за предыдущие дни в одной и в другой БД и ответ должен приходить за одинаковое время примерно.

Пример запроса:

SELECT
  (SELECT concat(p.latitude::TEXT, ' ', p.longitude::TEXT)
   FROM positions p
   WHERE p.route_list_id = rl.id
   ORDER BY p.time DESC
   LIMIT 1) as POSITION,
  *
FROM route_list_date rld
       INNER JOIN route_list rl on rld.id = rl.route_list_date_id
WHERE rld.date = '2020-02-17'

Answer 1

[Вячеслав Успенский]

Конечно может, у вашей тестовой базы в кеше могут быть совершенно другие данные.
Кстати время какое то очень большое: либо у вас с индексами проблема либо с запросом, подозреваю что второе, глядя на селект.

Comments

[revukvr]

Вячеслав Успенский, а как можно упростить запрос? Грубо говоря есть 2 таблицы. 1) Список машин, 2) координаты каждой машины.

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

[Вячеслав Успенский]

revukvr, покажите explain analyze - подскажу.

Кстати по запросу не совсем то, что вы говорите вижу. У вас маршрут создается на каждый день? Потому как в выборке вы берете последние координаты по маршруту, в то время как верхний запрос пытается ограничить выборку конкретным днем.

ЗЫ Вы часто пишете координаты? Под такие данные по хорошему надо колоночную бд, ту же TimescaleDB.

[revukvr]

Вячеслав Успенский, это Вам нужно?

Nested Loop (cost=0.00..760030.98 rows=70 width=217) (actual time=114.465..6848.310 rows=70 loops=1)
-> Seq Scan on route_list_date rld (cost=0.00..1.14 rows=1 width=20) (actual time=0.028..0.033 rows=1 loops=1)
Filter: (id = 360)
Rows Removed by Filter: 5
-> Seq Scan on route_list rl (cost=0.00..25.31 rows=70 width=165) (actual time=0.016..0.558 rows=70 loops=1)
Filter: (route_list_date_id = 360)
Rows Removed by Filter: 355
SubPlan 1
-> Limit (cost=10857.20..10857.20 rows=1 width=40) (actual time=97.803..97.803 rows=0 loops=70)
-> Sort (cost=10857.20..10863.76 rows=2624 width=40) (actual time=97.788..97.788 rows=0 loops=70)
Sort Key: p."time" DESC
Sort Method: quicksort Memory: 25kB
-> Seq Scan on positions p (cost=0.00..10844.08 rows=2624 width=40) (actual time=97.749..97.749 rows=0 loops=70)
Filter: (route_list_id = rl.id)
Rows Removed by Filter: 367302
Planning Time: 0.434 ms
Execution Time: 6848.756 ms

Да, маршрут создаётся каждый день. Вместо даты там должен быть current_date. ТО есть этот запрос должен вовращать актуальные данные на то время когда он делается.

За день может прийти около 3000 координат по одному маршруту. БД используется POSTGRESQL.

[Вячеслав Успенский]

revukvr, с индексами бедааа, причем по всем таблицам.

[revukvr]

Вячеслав Успенский, то есть нужно сделать индексацию и будет шустро работать?

[Вячеслав Успенский]

revukvr, как минимум, я не вижу чему у вас вообще выполняться хотя бы секунду

Answer 2

[Михаил Е]

ИМХО:
1. Чтобы запрос корректно отсек лишние данные у вас должен быть Актуальный индекс по полю "date" в таблице "route_list_date".
2. Не помешал был актуальный индекс по полю "id" в таблицах "route_list_date" и по полю "route_list_date_id" в таблице "route_list" (чтобы внутреннее соединение прошло быстрее.)

Answer 3

[Ivan Vakhrushev]

Время выполнения запроса может сильно варьироваться от нагрузки и состояния сервера.
Если у вас объём БД различается, то и время работы запроса будет различаться. Это нормально. Так и должно быть.
Здесь лучше всего смотреть на план исполнения запроса и его результирующую стоимость.
Добавьте к вашему запросу explain(analyze, buffers, verbose) и посмотрите на вывод БД.