Re: performance for high-volume log insertion
От | david@lang.hm |
---|---|
Тема | Re: performance for high-volume log insertion |
Дата | |
Msg-id | alpine.DEB.1.10.0904211142110.12662@asgard.lang.hm обсуждение исходный текст |
Ответ на | Re: performance for high-volume log insertion (david@lang.hm) |
Ответы |
Re: performance for high-volume log insertion
|
Список | pgsql-performance |
On Tue, 21 Apr 2009, david@lang.hm wrote: >> I see that >> you use %blah% to define variables inside your string. That's fine. >> There's no reason why you can't use this exact syntax to build a >> prepared query. No user-impact changes are necessary. Here's what you >> do: > > <snip psudocode to replace %blah% with $num> > > for some reason I was stuck on the idea of the config specifying the > statement and variables seperatly, so I wasn't thinking this way, however > there are headaches > > doing this will require changes to the structure of rsyslog, today the string > manipulation is done before calling the output (database) module, so all the > database module currently gets is a string. in a (IMHO misguided) attempt at > security in a multi-threaded program, the output modules are not given access > to the full data, only to the distiled result. > > also, this approach won't work if the user wants to combine fixed text with > the variable into a column. an example of doing that would be to have a > filter to match specific lines, and then use a slightly different template > for those lines. I guess that could be done in SQL instead of in the rsyslog > string manipulation (i.e. instead of 'blah-%host%' do 'blah-'||'%host') by the way, now that I understand how you were viewing this, I see why you were saying that there would need to be a SQL parser. I was missing that headache, by going the direction of having the user specify the individual components (which has it's own headache) David Lang
В списке pgsql-performance по дате отправления: