Re: RFC: Allow EXPLAIN to Output Page Fault Information
От | Jelte Fennema-Nio |
---|---|
Тема | Re: RFC: Allow EXPLAIN to Output Page Fault Information |
Дата | |
Msg-id | D6MJOHS7HZ80.3B17NDGUV6T47@jeltef.nl обсуждение исходный текст |
Ответ на | Re: RFC: Allow EXPLAIN to Output Page Fault Information (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: RFC: Allow EXPLAIN to Output Page Fault Information
Re: RFC: Allow EXPLAIN to Output Page Fault Information |
Список | pgsql-hackers |
On Tue Dec 24, 2024 at 4:52 PM CET, Tom Lane wrote: > torikoshia <torikoshia@oss.nttdata.com> writes: >> I have attached a PoC patch that modifies EXPLAIN to include page fault >> information during both the planning and execution phases of a query. > > Surely these numbers would be too unstable to be worth anything. What makes you think that? I'd expect them to be similarly stable to the numbers we get for BUFFERS. i.e. Sure they won't be completely stable, but I expect them to be quite helpful when debugging perf issues, because large numbers indicate that the query is disk-bound and small numbers indicate that it is not. These numbers seem especially useful for setups where shared_buffers is significantly smaller than the total memory available to the system. In those cases the output from BUFFERS might give the impression that that you're disk-bound, but if your working set still fits into OS cache then the number of page faults is likely still low. Thus telling you that the numbers that you get back from BUFFERS are not as big of a problem as they might seem.
В списке pgsql-hackers по дате отправления: