Zeoslib Portal

Posted: **24.10.2013, 01:23**

@all

in TZSQLMonitor, add time in miliseconds that was taken to execute query from prepare to fetch all rows. There is usefull when optimize the application querys.

Sample:

Code: Select all

2013-10-23 22:15:48 cat: Bind prepared, proto: postgresql-8, msg: Statement 455 : 1,1
2013-10-23 22:15:48 cat: exectime: 100ms Execute prepared, proto: postgresql-8, msg: Statement 455
2013-10-23 22:15:48 cat: exectime: 50ms Execute, proto: postgresql-8, msg: SELECT n.nspname,c.relname,a.attname,a.atttypid,a.attnotnull,a.atttypmod,a.attlen,a.attnum,pg_get_expr(def.adbin, def.adrelid) as adsrc,dsc.description  FROM pg_catalog.pg_namespace n  JOIN pg_catalog.pg_class c ON (c.relnamespace = n.oid)  JOIN pg_catalog.pg_attribute a ON (a.attrelid=c.oid)  LEFT JOIN pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND a.attnum = def.adnum) LEFT JOIN pg_catalog.pg_description dsc ON (c.oid=dsc.objoid AND a.attnum = dsc.objsubid)  LEFT JOIN pg_catalog.pg_class dc ON (dc.oid=dsc.classoid AND dc.relname='pg_class') LEFT JOIN pg_catalog.pg_namespace dn ON (dc.relnamespace=dn.oid AND dn.nspname='pg_catalog')  WHERE a.attnum > 0 AND NOT a.attisdropped AND c.relname = E's210ipe' ORDER BY nspname,relname,attnum

Posted: **24.10.2013, 08:37**

Hi,

This feature effectively adds overhead for all operations. So it's not something I really would consider adding.
However, I think you can implement this feature by adding a custom LogListener. (The way we do it for the test suite). Then you can add your own timers at will.
I don't know if you noticed we just started a new branch for logging developments? There we could also experiment with an alternative for your request.
Things that could be done:
- Add an sending object pointer to the logging-event which enables you to uniquely identify what object (connection, statement, resultset, ...)is logging something.
- Make sure query finalisation and row fetching CAN be logged (the new way, which means 'on demand', depending on the availabilyt of listeners)
- Standardize where logging events are fired.(eg. log the bind event before or after the client library calls?)

Do you feel like joining this effort? That way you can contribute to a well defined part of the functionality without risking to break the main development, but with a good chance to get the changes in zeoslib 7.2. You want me to add sourceforge user fhaut to our developer group (which equals granting you svn commit rights)? You're more than welcome!

Mark

Posted: **24.10.2013, 17:04**

@mdaems

I thought I'd add a variable of type "TDateTime" initializing with now() before method "TZQuery.InternalOpen" and after the end of the processing compare with current time and write to the log, only to objects TZQuery. And this only maded if the log is enabled to not slow down performance.

I want help zeoslib and appreciate your invitation to join the commit developers, my user is "fhaut" on sourceforge.
I see that is a path to learn the structure of the source code and will look the "new branch for logging developments" there is any documentation to assist in developing such rules or standards?

Posted: **29.10.2013, 20:41**

Mark?

@fauht

propose you read this link before? -> http://zeoslib.sourceforge.net/viewtopic.php?f=4&t=3671
Questions?

Zeoslib Portal

Feature Request - TZSQLMonitor "Exectime: 500ms"

Feature Request - TZSQLMonitor "Exectime: 500ms"

Re: Feature Request - TZSQLMonitor "Exectime: 500ms"

Re: Feature Request - TZSQLMonitor "Exectime: 500ms"

Re: Feature Request - TZSQLMonitor "Exectime: 500ms"