Re: That EXPLAIN ANALYZE patch still needs work
От | Greg Stark |
---|---|
Тема | Re: That EXPLAIN ANALYZE patch still needs work |
Дата | |
Msg-id | 87odx596hx.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: That EXPLAIN ANALYZE patch still needs work (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: That EXPLAIN ANALYZE patch still needs work
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > And two, that upper plan nodes seem much more affected than lower > ones. That makes sense because the execution cycle of an upper node > will involve touching more userspace data than a lower node, and > therefore more of the flushed TLB entries will need to be reloaded. I would have expected the opposite effect. If you only execute one instruction then the cache miss can make it take many times longer than normal. But as the number of instructions grows the cache gets repopulated and the overhead levels off and becomes negligible relative to the total time. The other option aside from gprof-like profiling would be to investigate those cpu timing instructions again. I know some of them are unsafe on multi-cpu systems but surely there's a solution out there. It's not like there aren't a million games, music playing, and other kewl kid toys that depend on accurate low overhead timing these days. -- greg
В списке pgsql-hackers по дате отправления: