Re: Planning time in explain/explain analyze
От | Tom Lane |
---|---|
Тема | Re: Planning time in explain/explain analyze |
Дата | |
Msg-id | 17920.1389302050@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Planning time in explain/explain analyze (Greg Stark <stark@mit.edu>) |
Ответы |
Re: Planning time in explain/explain analyze
|
Список | pgsql-hackers |
Greg Stark <stark@mit.edu> writes: > However I don't see the issue here. Two gettimeofday calls per query > plan is not really going to hurt even on systems where it's slow. I tend to agree with this, especially if the calls only occur when the user asks for the information (ie, does an EXPLAIN rather than just executing the query). > The only way two gettimeofday calls per query plan becomes an issue is > if you're executing non-cached queries repeatedly on data that's > entirely in ram. That means the query processing is entirely cpu-bound > and adding two syscalls could actually be noticeable. The mitigation > strategy would be to prepare and cache the query handle to execute it > again. This point weighs against the proposal that we time the work to fetch a previously-prepared query plan; if we do that then the "mitigation strategy" doesn't mitigate anything. In short then, I think we should just add this to EXPLAIN and be done. -1 for sticking the info into PlannedStmt or anything like that. regards, tom lane
В списке pgsql-hackers по дате отправления: