From: | Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Buffer usage in EXPLAIN and pg_stat_statements (review) |
Date: | 2009-10-05 03:22:15 |
Message-ID: | 20091005115056.9CE1.52131E4D@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 1. I would suggest something like "Blocks
> Read: %ld Hit: %ld Temp Read: %ld\n". See the way we handle output
> of sort type and space usage, for example.
I have some questions:
* Did you use single space and double spaces in your example intentionally?
* Should we use lower cases here?
* Can I use "temp" instead of "Temp Read" to shorten the name?
> 2. Similarly, in pg_stat_statements, the Counters structure could
> easily use the same names for the structure members that we already
> use in e.g. pg_stat_database - blks_hit, blks_read, and, say,
> blks_temp_read. In fact I tend to think we should stick with "blocks"
> rather than "buffers" overall, for consistency with what the system
> does elsewhere.
I agree to rename them into blks_*, but EXPLAIN (blocks) might be
misleading; EXPLAIN (buffer) can be interpreted as "buffer usage",
but normally we don't call it "block usage".
My suggestion is:
* EXPLAIN (buffers) prints (blocks read: %ld hit: %ld temp: %ld)
* auto_explain.log_buffers are not changed
* pg_stat_statements uses blks_hit and blks_read
> 4. "Instrumentation stack is broken" doesn't seem terribly helpful in
> understanding what has gone wrong.
This message is only for hackers and should not occur.
Assert() might be ok instead.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-10-05 03:36:20 | Re: Buffer usage in EXPLAIN and pg_stat_statements (review) |
Previous Message | Tom Lane | 2009-10-05 03:16:33 | Re: dblink memory leak |