Hallöchen!
Andreas Kretschmer writes:
> Torsten Bronger <bronger@physik.rwth-aachen.de> wrote:
>
>> I need statistics about the PG server load. At the moment, I use
>> for this
>>
>> SELECT tup_returned + tup_fetched + tup_inserted + tup_updated +
>> tup_deleted FROM pg_stat_database WHERE datname='mydb';
>>
>> However, the figures are absurdly high (> 100.000 rows per second).
>
> [...] And yes, a update is a delete and a insert. With your query
> you get 3 rows per one singel update (tup_updated + tup_deleted +
> tup_inserted). That's maybe not that what you expected.
Thank you, I will correct this.
> Not to mention, every operation affects the system-tables, so one
> single update, for instance, procude more than 3 table-operations.
But so many? My web application reports 10 new objects per second.
Of course, these are "compound" objects. They consist of at most 10
single table entries. This makes 100 rows/s. With further tables
being affected (news feed queue, table of last modifications etc),
let's assume 300 rows/s. Then, with your above remark, we get to
1000 rows/s. But this is a very much streched upper estimate.
I measure 180.000 rows/s. Thus, it is still too high by a factor of
180. Even if the server is not contacted at all, it's at 50 rows/s
just for its admistrative work.
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: torsten.bronger@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com