On Mon, 20 Apr 2009, Rainer Gerhards 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 ;)).
I asked the Postgres experts on the postgres-performance mailing list see the thread titled 'performance for high-volume log insertion' archives are at http://archives.postgresql.org/pgsql-performance/ so far I managed to go down a blind alley, but in the process I learned that postgres has implemented a binary API, but it's really only usefule if you are dealing with datatypes that are far more efficiant to deal with in binary form (dates and numbers primaril). so for rsyslog it looks like there is little, if any benifit from using binary mode. the non-string API does have one significant benifit, it eliminates the need to escape strings. but countering that is the need to define what will be in each string (for an aarbatrary number of strings), plus define what the SQL for the prepared statement is. I don't think this is a net win for complexity, and I agree with you that for large batches, I don't expect that the API mode will be noticably better. the thread left off (for tonight) with a question posted by the person who aswered most of my questions > Have you done any testing to compare COPY vs. INSERT using prepared > statements? I'd be curious to know how those compare and against > multi-value INSERTS, prepared and unprepared. I'll let you know if anyone responds to this. and if RB ot anyone else has comments on ths I would like to know (independantly of whatever rsyslog ends up doing ;-) David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
