Re: contrib/pg_stat_statements 1202 - Mailing list pgsql-hackers

From Vladimir Sitnikov
Subject Re: contrib/pg_stat_statements 1202
Date
Msg-id 1d709ecc0812050614o7d5ffd77o81c9c1b01bbe9bf1@mail.gmail.com
Whole thread Raw
In response to Re: contrib/pg_stat_statements 1202  (Greg Smith <gsmith@gregsmith.com>)
List 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 by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Optimizing DISTINCT with LIMIT
Next
From: Tom Lane
Date:
Subject: Re: Mostly Harmless: Welcoming our C++ friends