> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Monday, April 20, 2009 9:22 PM > To: rsyslog-users > Subject: Re: [rsyslog] RFC: On rsyslog output modules and support for > batchoperations > > On Mon, 20 Apr 2009, RB wrote: > > > On Mon, Apr 20, 2009 at 10:33, Rainer Gerhards > <[email protected]> wrote: > >> Excellent, but let me re-phrase: if you have a PostgreSQL expert at > hand, > >> that would be even more useful (I can do testing with PostgreSQL > myself, but > >> do not have access to Oracle - I overlooked that tiny little > restriction when > >> posting ;)). > > > > Perhaps more importantly for implementation-specific bits, perhaps we > > could clarify which we're discussing: procedures, functions, or > > prepared statements? The thread seems to jump back & forth between > > stored procedures and prepared statements, and although they are > > similar and often have a pure-SQL interface, they are not implemented > > everywhere. > > > > MySQL: PREPARE, CREATE PROCEDURE, CREATE FUNCTION > > PostgreSQL: PREPARE, CREATE FUNCTION > > Oracle: CREATE PROCEDURE, CREATE FUNCTION > > > > So, for PosgreSQL, you'd do something like Luis' earlier post: > > > > PREPARE rsyslog_insert(date, text) AS > > INSERT INTO foo VALUES($1, $2); > > EXECUTE rsyslog_insert('20090420-06:00', "log1"); > > EXECUTE rsyslog_insert('20090420-06:00', "log2"); > > EXECUTE rsyslog_insert('20090420-06:00', "log3"); > > by the way, this is not nessasrily the most efficiant way to get data > into > postgres (although it's far more efficiant than independant insert > statements like we do today. > > you can do begin;insert;insert;end > > you can do insert values (),(),(),(),() > > you can do prepare;execute;execute > > you can do a procedure or function that will insert the data into a > different table based on the time (think of it as dynafiles for > databases) > > you can do copy (and can probably combine this with prepared > statements, > procedures, and functions) > > which one is the most efficiant one depends on a lot of things (what > permissions you give the rsyslog user, how the database is setup, etc) > > it would be best if we can avoid coding one specific option into > rsyslog >
Definitely - I came down the database library API path because this is how omoracle is done AND I remember from past work that the API provides a lot of speed. But I am not a real database guy ;) If we can stay at a largely DB independent level with a simple API, I am all for that! Actually, it proves that the original design was that bad at all ;) Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
