|
|
|
Нужен ли outplan/baseplan в Postgres?
|
|||
|---|---|---|---|
|
#18+
Всем привет! Недавно спрашивал в facebook группе теперь решил спросить и тут. У меня есть вопросы к тем кто раньше сидел или сидит на Oracle и использует такую вещь как outplan/baseplan (фиксация плана запроса). Собственно хочется понять причины почему такой функционал появился в Oracle и нужен ли он в Postgres. На самом деле прототип у меня уже готов но появилось много сомнений в этой функциональности. Ваше мнение очень важно! PS прототип рабочий и позволяет сохранять запросы с дырками "по маске". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2015, 09:51 |
|
||
|
Нужен ли outplan/baseplan в Postgres?
|
|||
|---|---|---|---|
|
#18+
stalkerg, осторожно интересуюсь -- чем вас не устраивает Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2015, 10:36 |
|
||
|
Нужен ли outplan/baseplan в Postgres?
|
|||
|---|---|---|---|
|
#18+
qwwq, auto_explain позволяет вам просто в логах выводить планы запросов. Мой функционал позволяет сохранить конкретный план запроса и применять его ко всем остальным аналогичным запросам (по сути зафиксировать план запроса). Сохранение происходит в рамках сессии но работает для всех бэкендов. Почитайте про outplan в Oracle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2015, 10:48 |
|
||
|
Нужен ли outplan/baseplan в Postgres?
|
|||
|---|---|---|---|
|
#18+
stalkergqwwq, auto_explain позволяет вам просто в логах выводить планы запросов. Мой функционал позволяет сохранить конкретный план запроса и применять его ко всем остальным аналогичным запросам (по сути зафиксировать план запроса). Сохранение происходит в рамках сессии но работает для всех бэкендов. Почитайте про outplan в Oracle.1. я немного не люблю оракл и много -- ара-калоедов. 2. для "сохранить" план у меня есть prepare/execute. 3. жизнь показывает, что основные затраты планирования (запросов к сложно устроенным иерархиям) идут на вычитку статистики. По прогетым данным это уже милисекунды. И сплошь и рядом "такой же запрос" но с другими параметрами, надо перепланировать наново -- с другими параметрами--другие партиции, чеки и т.п. придут в движение. Т.е воспользоваться сохранённым планом "общего вида"-- даже и вредно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2015, 10:56 |
|
||
|
Нужен ли outplan/baseplan в Postgres?
|
|||
|---|---|---|---|
|
#18+
qwwq2. для "сохранить" план у меня есть prepare/execute. Оно не жардится между сессиями. Кроме того оно не всё сохраняет. qwwq3. жизнь показывает, что основные затраты планирования (запросов к сложно устроенным иерархиям) идут на вычитку статистики. По прогетым данным это уже милисекунды. И сплошь и рядом "такой же запрос" но с другими параметрами, надо перепланировать наново -- с другими параметрами--другие партиции, чеки и т.п. придут в движение. Т.е воспользоваться сохранённым планом "общего вида"-- даже и вредно. Тут задача не столько в скорости, сколько в надёжности: 1. Если кто то боится, что план поедет. 2. Если прям сейчас запрос выполняется не эффективно, а сам запрос поменять нету возможности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2015, 11:10 |
|
||
|
Нужен ли outplan/baseplan в Postgres?
|
|||
|---|---|---|---|
|
#18+
Зачем нужна такая функциональность в Oracle совершенно понятно. Т.к. на разных данных (дев, тест, прод) статистика данных может отличаться. В реальных ПРОМЫШЛЕННЫХ системах иногда бывает, что "план уехал". На тест'е все летает, на проде все стоит колом. Фиксация планов дает возможность такие проблемы убирать. Ну и вообще, в последних Oracle, оптимизатор больно "умный". Без такой возможности, в ряде случаев, на продакшене можно было бы сильно "горе от ума" огрести. В их же родной систему Oracle Customer Care & Billing вообще для критических запросов используется мега хит RULE. Типо нефиг сюда лазать со своим "больно умным" стоимостным оптимизатором ))). За PostgreSQL не скажу. Может тут такой проблемы СОПРОВОЖДЕНИЯ промышленных систем нет, но "сомнения в этой функциональности" мне не очень понятны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2015, 15:46 |
|
||
|
|
start [/forum/topic.php?fid=53&msg=39023640&tid=1997841]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
146ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 248ms |
| total: | 480ms |
| 0 / 0 |
