Re: understanding pg_stat* numbers
От | Oleg Bartunov |
---|---|
Тема | Re: understanding pg_stat* numbers |
Дата | |
Msg-id | Pine.GSO.4.62.0504011111340.14187@ra.sai.msu.su обсуждение исходный текст |
Ответ на | Re: understanding pg_stat* numbers ("Qingqing Zhou" <zhouqq@cs.toronto.edu>) |
Список | pgsql-hackers |
Qingqing, Thanks for the info, I do know all issues you mentioned. I want to know if there is any possibility to research performance problem in PostgreSQL without voodoo techiques, at least at the level of pg itself. At this aspect, I could answer myself: heap_blks_read is the # of blocks 'ordered' to read from disk and heap_blks_hit is the # of blocks read from pg buffers. One mystery remains, why stats show heap_blks_read > 0 for indexed search ? select 1 from foo where id=5 I did pg_stat_reset() before run query. Oleg On Thu, 31 Mar 2005, Qingqing Zhou wrote: > > "Oleg Bartunov" <oleg@sai.msu.su> writes >> From my experiments I feel heap_blks_read is the table blocks read from > disk, >> well, sort of, and heap_blks_hit - from buffer. At least, I observed when > I >> repeat the same query several times (heap_blks_read+heap_blks_hit) doesn't >> changed while more blocks come from heap_blks_hit. >> > > PG relies on the OS to schedule the *real* IO you mean. So heap_blks_read > may come from OS kernel buffer, or from disk. You can minimize/disable your > OS file buffers (if it supports this function) or change the mdopen() using > O_DIRECT to make the heap_blks_read approaches the *real* IO if you want - > but for sure this hurts performance. > >> It's common in db worlds to have IO statistics (timings are not important) >> to research algorithms and implementation. >> > > The *real* IO you mean might be an elegant choice in academic, but is a > subjective matter in practice. For example, we can only assume statistically > N random IO costs the same time with another N random IO, because disk > header has its own scheduling logic controlled by the layout of these > blocks, etc, which you can't decide. Not to speak of the IOs in concurrent > environment. If so, use heap_blks_read/write is already good enough? > > Regards, > Qingqing > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
В списке pgsql-hackers по дате отправления: