Комментарии 23
А что если бы мы сказали постгресу, что сканирование индекса нельзя использовать ни при каких условиях?
И это тоже давайте отключим:
вот тут непонятно, каким образом и что он отключал?
С самого начала вот тут: www.postgresql.org/docs/9.4/static/runtime-config-query.html
Да, автор не уточнил, какие именно «гайки» он крутил, что даже очень хорошо, на мой взгляд :) Неумелое кручение этих гаек может привести к поиску подземного стука потом в приложении.
Тема визардов больше ко всяким пакетам типа WAMP относится, но никак не к тем, кто использует postgres ежедневно и хочет ещё более детально в нём разбираться. Но ваш намёк на тупость понят.
Вы какие-то странные выводы из сказанного делаете, но дело ваше.
Подождите, давайте разберём.
Всё понятно, автор не уточнил
К чему был этот комментарий? Вы меня считаете тем, кто будет неумело им пользоваться? Тогда загляните в мой профиль. Я на хабре 9 лет, не считая сколько вообще занимаюсь айти.
Да, автор не уточнил, какие именно «гайки» он крутил
Всё понятно, автор не уточнил
что даже очень хорошо, на мой взгляд :) Неумелое кручение этих гаек может привести к поиску подземного стука потом в приложении.
К чему был этот комментарий? Вы меня считаете тем, кто будет неумело им пользоваться? Тогда загляните в мой профиль. Я на хабре 9 лет, не считая сколько вообще занимаюсь айти.
Я своих собеседников никогда не считаю по-умолчанию тупыми или невежественными. Ровно поэтому, когда коллега выше упомянул ссылку на документацию, я счел, что вы, являясь, наверняка, человеком образованным и сообразительным, найдете для себя там ответ.
Именно поэтому я оставил свой комментарий, рассчитывая на то, что вы его оцените именно с позиции человека, имеющего опыт в отрасли. Кручение «гаек» планировщика является очень опасным приемом, который в неумелых руках приводит к тому, что ранее работавшие запросы внезапно начинают дико тормозить, когда меняется статистика, собираемая базой данных, и, как следствие, выстраиваемый план запроса. То, что раньше было неэффективным и столь неэлегантным образом отключалось, внезапно стало жизненноважным для хорошей производительности.
Мой комментарий никак не касался ваших умственных способностей, профессионального опыта или стажа пребывания на Habrahabr.
Именно поэтому я оставил свой комментарий, рассчитывая на то, что вы его оцените именно с позиции человека, имеющего опыт в отрасли. Кручение «гаек» планировщика является очень опасным приемом, который в неумелых руках приводит к тому, что ранее работавшие запросы внезапно начинают дико тормозить, когда меняется статистика, собираемая базой данных, и, как следствие, выстраиваемый план запроса. То, что раньше было неэффективным и столь неэлегантным образом отключалось, внезапно стало жизненноважным для хорошей производительности.
Мой комментарий никак не касался ваших умственных способностей, профессионального опыта или стажа пребывания на Habrahabr.
Спасибо за «рекламу» http://explain.depesz.com — очень полезная штука.
Жги ещё, отлично что такие статьи на русском теперь появляются!
Спасибо, очень интересно. Жду продолжения.
Интересны принципы и методики настройки параметров postgresql, для управления механизмами оценки запросов.
Интересны принципы и методики настройки параметров postgresql, для управления механизмами оценки запросов.
Статья хорошая, единственное, что вам надо тему сделать более четкую. Сложно вашу статью будет потом нагуглить :-)
«Основы стоимостной оптимизации» — автор Дж. Льюис
Вот наше все, для понимания стоимостной оптимизации (хоть там и про oracle)
Вот наше все, для понимания стоимостной оптимизации (хоть там и про oracle)
А постгрессовский explain умеет возвращать план в табличном виде как оракл, т.е. отдельно столбец Plan operation, Owner, Object, Partition ID/Start/Stop, Cost, Cardinality, Access predicates, Filter predicates, etc?
Почти полный список полей
Describing VIEW SYS.V_$SQL_PLAN...
Name Null? Type
----------------------------------------- -------- ----------------------------
ADDRESS RAW(8)
HASH_VALUE NUMBER
SQL_ID VARCHAR2(13)
PLAN_HASH_VALUE NUMBER
CHILD_ADDRESS RAW(8)
CHILD_NUMBER NUMBER
TIMESTAMP DATE
OPERATION VARCHAR2(30)
OPTIONS VARCHAR2(30)
OBJECT_NODE VARCHAR2(40)
OBJECT# NUMBER
OBJECT_OWNER VARCHAR2(30)
OBJECT_NAME VARCHAR2(30)
OBJECT_ALIAS VARCHAR2(65)
OBJECT_TYPE VARCHAR2(20)
OPTIMIZER VARCHAR2(20)
ID NUMBER
PARENT_ID NUMBER
DEPTH NUMBER
POSITION NUMBER
SEARCH_COLUMNS NUMBER
COST NUMBER
CARDINALITY NUMBER
BYTES NUMBER
OTHER_TAG VARCHAR2(35)
PARTITION_START VARCHAR2(64)
PARTITION_STOP VARCHAR2(64)
PARTITION_ID NUMBER
OTHER VARCHAR2(4000)
DISTRIBUTION VARCHAR2(20)
CPU_COST NUMBER
IO_COST NUMBER
TEMP_SPACE NUMBER
ACCESS_PREDICATES VARCHAR2(4000)
FILTER_PREDICATES VARCHAR2(4000)
PROJECTION VARCHAR2(4000)
TIME NUMBER
QBLOCK_NAME VARCHAR2(30)
REMARKS VARCHAR2(4000)
OTHER_XML CLOB
Сокращенный пример
------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |IN-OUT| PQ Distrib |
------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 29 (100)| | | |
| 1 | PX COORDINATOR | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10000 | 8168 | 15M| 29 (0)| 00:00:01 | P->S | QC (RAND) |
| 3 | VIEW | | 8168 | 15M| 29 (0)| 00:00:01 | PCWP | |
| 4 | COLLECTION ITERATOR PICKLER FETCH| PARALLELPOPUINDEX | 8168 | | 29 (0)| 00:00:01 | PCWP | |
| 5 | PX BLOCK ITERATOR | | 33M| 388M| 31316 (1)| 00:06:16 | PCWC | |
|* 6 | TABLE ACCESS FULL | XXXXXX | 33M| 388M| 31316 (1)| 00:06:16 | PCWP | |
------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
6 - access(:Z>=:Z AND :Z<=:Z)
В табличном виде нет, но можно задать формат FORMAT { TEXT | XML | JSON | YAML } (http://www.postgresql.org/docs/9.4/static/sql-explain.html), а результат уже машинно анализировать.
JSON представление теоретически можно превратить в таблицу функциями postgresql.
JSON представление теоретически можно превратить в таблицу функциями postgresql.
В виде таблички придется извращаться, но например в виде json можно для простоты.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Объясняя необъяснимое