Я новичок в проектировании баз данных, надеясь научиться экспериментировать и внедрять, и я уверен, что какая-то версия этого вопроса была задана в рамках проектирования баз данных в целом, но это специфично для Таблицы.
У меня есть несколько панелей, которые рисуют из таблицы базы данных PostgreSQL, которая содержит несколько миллионов строк данных. Производительность перерисовки представлений довольно медленная (т. Е. Если я выберу другой параметр, появится всплывающее окно Tableau Executing SQL query, которое часто занимает несколько минут).
Я отлаживал это, используя параметр записи производительности в Tableau, экспортируя SQL-запросы, которые Tableau использует, в текстовый файл, а затем используя EXPLAIN ANALYZE, чтобы выяснить, какие именно были узкие места. К сожалению, я не могу опубликовать сами SQL-запросы, но я создал надуманный пример ниже, чтобы он был максимально полезным. Вот как выглядит мой стол в настоящее время. Фактические значения , отображаемые таблицей , находятся в зеленый , а столбцы, на которые у меня есть ссылки на внешний ключ, находятся в желтый :
Я вижу в плане запросов, что существует много дорогостоящих сканирований кучи растровых изображений, в которых используются фильтры, используемые в Tableau на веб-интерфейсе neighborhood_id, view, animal, date_updated, animal_name.
Я пытался разместить несколько индексов в этих полях, но после повторного запуска запросов не похоже, что планировщик запросов PG решает использовать эти индексы.
Таким образом, мое предлагаемое решение состоит в создании ссылок на внешние ключи для каждого из этих полей (neighborhood_id, view, animal, date_updated, animal_name) - снова, желтый цвет соответствует FK :
Я надеюсь, что эти ссылки FK заставят планировщика запросов использовать сканирование индекса вместо последовательного сканирования или сканирования кучи растрового изображения. Тем не менее, мои вопросы
Раньше все данные были более или менее сохранены в этой одной таблице, с
два соединения с таблицами shelter и age_of_animal. Теперь эта таблица
будет присоединен к 8 меньшим подтаблицам - будут ли эти объединения резко
снизить производительность? Подтаблицы довольно малы (т. Е. animal
таблица будет иметь только 40 записей).
Я знаю, что на вопрос трудно ответить, не видя фактического
запрос и план запроса, но каковы некоторые причины высокого уровня
планировщик запросов выбрать не использовать индекс? Я прочитал несколько статей, таких как «Почему Postgres не всегда использует индекс» , но в основном они относятся к случаям, когда это небольшая таблица и простой запрос, где стоимость поиска по индексу выше, чем просто пересекая ряды. Я не думаю, что это применимо к моему случаю - у меня миллионы строк и сложный фильтр на 5+ столбцах.
- Может ли PG Query Planner с большей вероятностью использовать несколько столбцов
индексы для коллекции столбцов внешнего ключа по сравнению с обычными
столбцы? Я знаю, что PG не добавляет индексы автоматически
внешние ключи , так что я думаю, мне все еще нужно будет добавить индексы после
создание ссылок на внешний ключ.
Конечно, ответы на мои вопросы могут быть «Почему бы вам просто не попробовать и посмотреть?», Но в этом случае рефакторинг такой большой таблицы довольно дорог, и я хотел бы получить некоторую интуицию о том, стоит ли это стоимость до его проведения.