Hey Wim and all,
On Wed, Jan 19, 2005 at 05:17:11PM -0800, Wim Kerkhoff wrote:
> I didn't even know that directive existed - must be a new one. So I'm
> using the default, which I think is to try an update first.
Precisely. It has been introduced (let's see the ChangeLog, blabla ...)
in May/June 2004, with the last 0.6.x version.
> I suppose it's a toss between extra database operations (try update,
> then insert if no records updated) and extra disk space used.
Yes, again. The unique case which allows to avoid both extra DB operations
and disk space consumption is an accounting environment where there isn't
the need to timely report *live* statistics.
With the 'sql_dont_try_update' enabled, each INSERT need to be differentiated
by the others, even when writing the same flow. The simplest way to achieve
this, is to enable timestamps ('stamp_inserted' field is by default into
the table's primary key) enabling the 'sql_history' directive and making
it to match the 'sql_refresh_time' value; this way each time the cache will
be purged, this will happen in a different historical timeslot (so, giving
each purging event a different value to the 'stamp_inserted' field).
When there is the need of live statistics, as correctly pointed out by Wim,
this approach may easily translate into timeslot 'compression', to have fresh
statistics (think to a web interface) at the expense of extra disk space.
Furthermore, if the statistics need to be presented with a coarser granularity
(the straight example is: you feed the counters each minute, in order to be
refresh-button friendly, and the users need to be presented hourly statistics),
you will also need to rejoin the counters, which may result in being even
more resource disruptive.
Cheers,
Paolo
