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

From Greg Smith
Subject Re: contrib/pg_stat_statements 1202
Date
Msg-id Pine.GSO.4.64.0812050330520.22750@westnet.com
Whole thread Raw
In response to Re: contrib/pg_stat_statements 1202  ("Vladimir Sitnikov" <sitnikov.vladimir@gmail.com>)
Responses Re: contrib/pg_stat_statements 1202  ("Vladimir Sitnikov" <sitnikov.vladimir@gmail.com>)
List pgsql-hackers
On Fri, 5 Dec 2008, Vladimir Sitnikov wrote:

>> Oracle's approach is to have the explain command stuff the results into a
>> table. That has advantages for tools, especially if you want to be able to
>> look at plans generated by other sessions.
>
> I do not believe that workflow makes sense. I have never ever thought of it.

The main benefit is that you can track how EXPLAIN plans change over time. 
Archive a snapshot of what the plans for all your common queries look like 
every day, and the day one of them blows up and starts doing something 
wrong you've got a *lot* more information to work with for figuring out 
what happened--whether it was a minor query change, some stats that got 
slowly out of whack, etc.  I wouldn't just immediately dismiss that 
workflow as unsensible without thinking about it a bit first, there are 
some good advantages to it.

Greg Sabino Mullane had a neat blog entry on saving plans to tables in 
PostgreSQL, unfortunately the Planet PostgreSQL outage seems to have eaten 
it.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD


pgsql-hackers by date:

Previous
From: Kurt Harriman
Date:
Subject: Mostly Harmless: Welcoming our C++ friends
Next
From: Gregory Stark
Date:
Subject: Re: In-place upgrade: catalog side