Re: contrib/pg_stat_statements 1202

Поиск
Список
Период
Сортировка
От Vladimir Sitnikov
Тема Re: contrib/pg_stat_statements 1202
Дата
Msg-id 1d709ecc0812050614o7d5ffd77o81c9c1b01bbe9bf1@mail.gmail.com
обсуждение исходный текст
Ответ на Re: contrib/pg_stat_statements 1202  (Greg Smith <gsmith@gregsmith.com>)
Список pgsql-hackers
The main benefit is that you can track how EXPLAIN plans change over time.
It is not required to output plan into some table to be able track it over time. If EXPLAIN returns a table, it is up to you to perform "insert into history select * from explain(...)".

Workflow that does not make sense for me is "look at plans generated _into some plan_table_ by other sessions in Oracle".
I am 100% sure it really makes sense have some view like pg_execute_plan that will reveal execution plans for currently running queries (see v$sql_plan in Oracle). However, I would stress once again I have no idea what the sense could be in "one session explained into plan_table, while the other reads that plan".

Does that make sense?

Regards,
Vladimir Sitnikov

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: Optimizing DISTINCT with LIMIT
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Mostly Harmless: Welcoming our C++ friends