![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
| author | oetiker <oetiker@a5681a0c-68f1-0310-ab6d-d61299d08faa> | |
| Fri, 7 Nov 2008 14:07:53 +0000 (14:07 +0000) | ||
| committer | oetiker <oetiker@a5681a0c-68f1-0310-ab6d-d61299d08faa> | |
| Fri, 7 Nov 2008 14:07:53 +0000 (14:07 +0000) | ||
| commit | ac2ef60748fac2c73a71a090a39e001408599529 | |
| tree | 10c17554c508aa59ac395f6ff9ff220bf333ce38 | tree | snapshot |
| parent | 48406456c590ab4ebe32d814f19b884eb5b012f1 | commit | diff |
As some of you may know that I have created a patch for rrdtool 1.2 a few years ago, so that a database could be queried for
values for graphing.
The patch has been mostly rewritten and the following changes have been made:
* high dependency on mysql has been reduced by avoiding the
temporary tables (which was bad for mysql replication)
* The number of executed SQL-Statements for one CDEF has been
reduced to 1 compared to 11 SQLs (including CREATE TEMPORARY
TABLE) - for patch against version 1.2
* All consolidation is done in rrdtool itself (MIN,MAX,AVERAGE)
* Additional consolidation functions are COUNT and SIGMA, which give
information on statistics on a per "time-bin" basis.
* All these consolidation values are always returned as separate
columns, that are returned by RRD and the consolidation function
given as Argument is ignored.
Main reason is that this way there is only one call to rrd_fetcht
and thus the database even if we need to fetch for example min,
avg and max. Compare this to 3 calls in case of different
consolidation functions - and if you want to get SIGMA and COUNT
as well it is still only one call to the backend and the database.
* Some previous existing features have been taken out at the moment
to allow for this reduced set of SQL queries.
o prediction using the values from the last X days at the same
time
o the corresponding sigma calculation
* The idea is to create generic CDEF's that will do the same thing,
but that is also available when using RRD-files (similar to TREND,
but with another scope)
This will get posted as a separate patch.
* Overall performance should be much better and the patch as a whole
simpler.
* The patch also includes modifications to the configuration
infrastructure, to make libdbi support optional.
-- Martin Sperl
git-svn-id: svn://svn.oetiker.ch/rrdtool/trunk@1650 a5681a0c-68f1-0310-ab6d-d61299d08faa
values for graphing.
The patch has been mostly rewritten and the following changes have been made:
* high dependency on mysql has been reduced by avoiding the
temporary tables (which was bad for mysql replication)
* The number of executed SQL-Statements for one CDEF has been
reduced to 1 compared to 11 SQLs (including CREATE TEMPORARY
TABLE) - for patch against version 1.2
* All consolidation is done in rrdtool itself (MIN,MAX,AVERAGE)
* Additional consolidation functions are COUNT and SIGMA, which give
information on statistics on a per "time-bin" basis.
* All these consolidation values are always returned as separate
columns, that are returned by RRD and the consolidation function
given as Argument is ignored.
Main reason is that this way there is only one call to rrd_fetcht
and thus the database even if we need to fetch for example min,
avg and max. Compare this to 3 calls in case of different
consolidation functions - and if you want to get SIGMA and COUNT
as well it is still only one call to the backend and the database.
* Some previous existing features have been taken out at the moment
to allow for this reduced set of SQL queries.
o prediction using the values from the last X days at the same
time
o the corresponding sigma calculation
* The idea is to create generic CDEF's that will do the same thing,
but that is also available when using RRD-files (similar to TREND,
but with another scope)
This will get posted as a separate patch.
* Overall performance should be much better and the patch as a whole
simpler.
* The patch also includes modifications to the configuration
infrastructure, to make libdbi support optional.
-- Martin Sperl
git-svn-id: svn://svn.oetiker.ch/rrdtool/trunk@1650 a5681a0c-68f1-0310-ab6d-d61299d08faa