Skip site navigation (1) Skip section navigation (2)

Re: Patch: add timing of buffer I/O requests

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Ants Aasma <ants(at)cybertec(dot)at>, Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch: add timing of buffer I/O requests
Date: 2012-04-28 16:49:44
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ... You might want to revisit the issue of how the new
> columns in pg_stat_statements are named, as well.  I am not sure I'm
> happy with that, but neither am I sure that I know what I'd like
> better.  It's not too clear that the timing is specifically for data
> block reads and writes, for example.

Well, the names "time_read" and "time_write" are certainly out of step
with every other stats view in the system; everyplace else, such columns
are named "something_time" (and even in this view itself the other
timing column is "total_time", not "time_total").  So that's got to
change.  We could just reverse the word order to "read_time" and
"write_time", or we could do something like "buf_read_time" or
"data_read_time".  IIUC block_read_time/block_write_time in the
pg_stat_database view are database-wide totals for the same numbers, so
perhaps the pg_stat_statements column names should be consistent with
those.  I am kinda wondering though why those columns spell out "block"
where every single other column name in the stats views uses the
abbreviation "blk".

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2012-04-28 16:56:04
Subject: Re: Patch: add timing of buffer I/O requests
Previous:From: Aakash GoelDate: 2012-04-28 16:31:46
Subject: Re: Welcome 2012 GSOC students

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group