Re: contrib/pg_stat_statements 1202
От | Greg Smith |
---|---|
Тема | Re: contrib/pg_stat_statements 1202 |
Дата | |
Msg-id | Pine.GSO.4.64.0812050330520.22750@westnet.com обсуждение исходный текст |
Ответ на | Re: contrib/pg_stat_statements 1202 ("Vladimir Sitnikov" <sitnikov.vladimir@gmail.com>) |
Ответы |
Re: contrib/pg_stat_statements 1202
|
Список | 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 по дате отправления: