Руководства по настройке запросов PostgreSQL? - PullRequest
19 голосов
/ 09 октября 2009

Я нашел ряд ресурсов, в которых рассказывается о настройке сервера базы данных, но я не нашел много информации о настройке отдельных запросов.

Например, в Oracle я мог бы попытаться добавить подсказки, чтобы игнорировать индексы или использовать сортировку-слияние против коррелированных объединений, но я не могу найти много о настройке Postgres, кроме с использованием явных объединений и рекомендации при таблицах массовой загрузки .

Существуют ли какие-либо такие руководства, чтобы я мог сосредоточиться на настройке наиболее выполняемых и / или неэффективных запросов, надеюсь, без ущерба для текущих хорошо выполняющихся запросов?

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

обновление :

Я должен был упомянуть, что я взял все классы Oracle DBA вместе с их классами моделирования данных и настройки SQL еще в 8i дней ... так что я знаю о "EXPLAIN", но это больше, чтобы рассказать вам, что происходит неправильно с запросом, не обязательно, как сделать его лучше. (Например, считаются ли «while var = 1 или var = 2» и «while var in (1,2)» одинаковыми при создании плана выполнения? Что если я делаю это с 10 перестановками? Когда используются несколько столбцов? Используемые индексы? Есть ли способы заставить планировщик оптимизировать работу для быстрого старта против самого быстрого финиша? С какими «ошибками» я могу столкнуться при переходе с mySQL, Oracle или некоторых других СУБД?)

Я мог бы написать любой сложный запрос десятками, если не сотнями способов, и я надеюсь, что мне не придется пробовать их все и найти, какой из них лучше всего работает методом проб и ошибок. Я уже обнаружил, что «SELECT count (*)» не будет использовать индекс, но «SELECT count (primary_key)» будет ... возможно, документ «PostgreSQL для опытных пользователей SQL», который объясняет типы запросов к избегать, и как лучше переписать их, или как заставить планировщика справиться с ними лучше.

обновление 2:

Я обнаружил Сравнение различных реализаций SQL , которое охватывает PostgreSQL, DB2, MS-SQL, mySQL, Oracle и Informix, и объясняет, как, как и что объясняет, что вы можете попытаться сделать, и его раздел ссылок связан с эквивалентами баз данных Oracle / SQL Server / DB2 / Mckoi / MySQL (что и предполагает его название) и с викибуком справочник по диалектам SQL , который охватывает все, что люди вносят ( включает в себя некоторые DB2, SQLite, MySQL, PostgreSQL, Firebird, Vituoso, Oracle, MS-SQL, Ingres и Linter).

Ответы [ 6 ]

12 голосов
/ 09 октября 2009

Что касается плохо выполняющихся запросов - объясните, проанализируйте и прочитайте.

Вы можете разместить на сайте результаты объяснения анализа, например объяснение.depesz.com - это поможет вам найти элементы, которые действительно занимают больше всего времени.

7 голосов
/ 16 марта 2010

Существует хороший онлайн-инструмент, который выводит EXPLAIN ANALYZE и графически показывает критические детали (например, неправильные оценки, горячие точки и т. Д.)

http://explain.depesz.com/help

Кстати, я думаю, что опубликованные запросы становятся общедоступными, и спам-боты ударили по ссылке «предыдущий поясняет».

5 голосов
/ 09 октября 2009

К сожалению, единственный способ настроить запрос в Postgres - это настроить базу данных, лежащую в его основе. В oracle вы можете установить все эти параметры по запросу на основе запроса, превзойти план оптимизатора в процессе, но в Postgres вы в значительной степени зависите от оптимизатора, хорошо это и плохо.

5 голосов
/ 09 октября 2009

http://www.postgresql.org/docs/current/static/indexes-examine.html

Вы можете дать подсказки: SET enable_indexscan TO false; заставит PostgreSQL не использовать индексы

4 голосов
/ 09 октября 2009

Инструмент PGAdmin3 включает в себя графический инструмент для объяснения того, как обрабатывается запрос. Это также особенно полезно для отображения места сканирования таблицы.

3 голосов
/ 09 октября 2009

Лучшее, что я видел, здесь: http://wiki.postgresql.org/wiki/Using_EXPLAIN,, но последний PDF-документ от 2008 года, так что может быть что-то более новое. Мне интересно услышать ответы других пользователей.

Кроме того, что-то назревает в пакетах contrib: http://www.sai.msu.su/~megera/wiki/plantuner

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...