2 почти идентичных выбора в одной и той же таблице БД занимают совершенно разное время для выполнения

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

У меня есть одна БД отчетов, она заполнена данными из спутниковых баз данных на многих небольших машинах. Выборки данных выполняются одинаково, каждые 20 минут для каждой спутниковой БД. Они используют все тот же сценарий. Однако они находятся на разных установках, разбросанных по всей стране.

Теперь у меня есть один SELECT, используемый отчетами Pentaho, которые выполняются в той же таблице БД в этой БД отчетов. и в то время как выполнение одного SELECT занимает миллисекунды, другое занимает буквально часы. Они оба выполняются над одной и той же таблицей, в одной БД, работающей на одном и том же оборудовании.

Быстрый:

SELECT
 res.ticket_id,
 res.entry_zone,
 res.entry_time,
 res.exit_time,
 res.parking_time,
 res.cost,
 co.org_name,
 cu.firstname,
 cu.surname,
 a.name AS article_name,
 res.car_id 
FROM (SELECT
 lh.ticket_id,
 z.name AS entry_zone,
 lh.park_entered AS entry_time,
 lh.park_leaved AS exit_time,
 interval_to_hourminsec(lh.park_leaved - lh.park_entered) AS parking_time,
 lh.cost,
 lh.article_id,
 sa.contrib_user_id,
 fpl.car_id
 FROM longterm_history lh, zones z, sold_articles sa, flexcore_passing_log fpl
 WHERE lh.park_leaved BETWEEN  '2017-12-18 00:00' AND  '2017-12-19 23:59'
 AND sa.ticket_id = lh.ticket_id
 AND lh.entry_zone = z.zone_number
 AND lh.passlog_id = fpl.id
 AND lh.park_uuid = 100068
 AND z.park_uuid = 100068
 AND sa.park_uuid = 100068
 AND fpl.park_uuid = 100068
 AND lh.entry_zone = 1
) AS res 
LEFT OUTER JOIN articles a ON res.article_id = a.article_id AND a.park_uuid = 100068 
LEFT OUTER JOIN cont_users cu ON res.contrib_user_id = cu.id AND cu.park_uuid = 100068 
LEFT OUTER JOIN cont_orgs co ON cu.org_id = co.id AND co.park_uuid = 100068 
ORDER BY res.exit_time ASC

Медленно:

SELECT
 res.ticket_id,
 res.entry_zone,
 res.entry_time,
 res.exit_time,
 res.parking_time,
 res.cost,
 co.org_name,
 cu.firstname,
 cu.surname,
 a.name AS article_name,
 res.car_id 
FROM (SELECT
 lh.ticket_id,
 z.name AS entry_zone,
 lh.park_entered AS entry_time,
 lh.park_leaved AS exit_time,
 interval_to_hourminsec(lh.park_leaved - lh.park_entered) AS parking_time,
 lh.cost,
 lh.article_id,
 sa.contrib_user_id,
 fpl.car_id
 FROM longterm_history lh, zones z, sold_articles sa, flexcore_passing_log fpl
 WHERE lh.park_leaved BETWEEN  '2017-12-18 00:00' AND  '2017-12-19 23:59'
 AND sa.ticket_id = lh.ticket_id
 AND lh.entry_zone = z.zone_number
 AND lh.passlog_id = fpl.id
 AND lh.park_uuid = 100146
 AND z.park_uuid = 100146
 AND sa.park_uuid = 100146
 AND fpl.park_uuid = 100146
 AND lh.entry_zone = 1
) AS res 
LEFT OUTER JOIN articles a ON res.article_id = a.article_id AND a.park_uuid = 100146 
LEFT OUTER JOIN cont_users cu ON res.contrib_user_id = cu.id AND cu.park_uuid = 100146 
LEFT OUTER JOIN cont_orgs co ON cu.org_id = co.id AND co.park_uuid = 100146 
ORDER BY res.exit_time ASC

как узнать где проблема, из-за чего выполняется второй SELECT часов?

Я использую postgres SQL, версия сервера 9.6.3. Данные извлекаются в базы данных с помощью интеграции данных Pentaho.

Редактировать:

После запуска обоих запросов через EXPLAIN (ANALYZE, BUFFERS) самая большая существенная разница в этой части:

                                           ->  Bitmap Index Scan on longterm_history_park_uuid_idx  (cost=0.00..7609.82 rows=352718 width=0) (actual time=492.753..492.753 rows=354537 loops=1)
                                                 Index Cond: (park_uuid = 100068)
                                                 Buffers: shared read=1238

                                           ->  Bitmap Index Scan on longterm_history_park_uuid_idx  (cost=0.00..453.11 rows=20890 width=0) (actual time=4.680..4.680 rows=40021 loops=466475)
                                                 Index Cond: (park_uuid = 100146)
                                                 Buffers: shared hit=65306361 read=139

и кажется, что второй SELECT медленнее loops=466475 вместо loops=1 dne первым SELECT. Но я понятия не имею, что это значит и как это исправить.

Редактировать2:

У меня есть инструмент для обмена планами в Интернете, вот ссылки:

Быстрый запрос: https://explain.depesz.com/s/oYQLB

Медленный запрос: https://explain.depesz.com/s/uOtf

Медленный запрос выполнялся быстро, пока выборка была отключена: https://explain.depesz.com/s/4h4F< /а>