> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Friday, April 24, 2009 9:30 AM > To: rsyslog-users > Subject: Re: [rsyslog] [PERFORM] performance for high-volume > loginsertion(fwd) > > On Fri, 24 Apr 2009, Rainer Gerhards wrote: > > >> -----Original Message----- > >> From: [email protected] [mailto:rsyslog- > >> [email protected]] On Behalf Of [email protected] > >> > >> On Fri, 24 Apr 2009, Rainer Gerhards wrote: > >> > >>>> -----Original Message----- > >>>> From: [email protected] [mailto:rsyslog- > >>>> [email protected]] On Behalf Of [email protected] > >>> > >>>> that logic can work for every module that needs it, so this > >> shouldn't > >>>> be > >>>> an issue.. I was mixing up the API with the need for a config > >> variable. > >>>> > >>>> David Lang > >>> > >>> Lol, our messages crossed. Still the question is if the > stringbuilder > >> should > >>> support this mode. If so, we need to make deep changes to the way > the > >>> property replacer works, thus I am hesitant to do this without real > >> needs > >>> (not just because of the work to be done, but also because of the > >> extra > >>> complexity [read: bugs, performance] it introduces). > >> > >> if the string builder is not in the core, the output module can do > the > >> work for 'mid' as/if needed. > >> > >> table it for now. > >> > >> food for thought (which may affect the decision when it happens), > there > >> is > >> benifit in doing the database equivalent of dynafiles (inserting > into > > > > Just to avoid misunderstanding: today, this is easy to acomplish - > you just > > need to use a property replacer expression inside the template string > like > > this "insert into syslog%hostname% ...". > > correct (as long as you didn't need to create the tables) > > > That, of course, will not work any longer if we go for prepared > statements > > (indeed another subtlety). I'd still expect that it works with the > begin... > > insert* ... end exec calls. > > it will work with the begin;insert;end approach > > for prepared statements you would need to prepare one for each > destination > (similar to creating/opening files), and if you ended up doing copy or > multi-value inserts you would need to do seperate ones for different > destinations. > > but in any case, issues for another day.
Yep - and not only because of time zones ;) I think it is vital to get the calling interface ready (we had quite some progress already :)). The layers below it are important (to help crafting he interface), but some issues I think do not need to be explored in full detail at this level. The bottom line, I think, is that this is a database-specific problem and other plugins probably do not have any such issue. So, we could handle that in a database abstraction, but not the general calling interface (assuming that the calling interface provides the necessary plumbing). Please all let me know if I am overlooking something. Thanks, Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
