> > > I think transactions are more important here. We need to > look more > > > closely at that. > > > > Considering Bacula runs a *lot* of commands that are almost > the same, > > differeing only in data, it would probalby be a noticable > gain using > > prepared statements (that probably goes for all dbs that > support them). > > That'll cut out a lot of per-statement overhead. > (PQexecPrepared etc) > > > > I have no idea how much work that would involve in the > backend, though > > - if queries are always passed as just plaintext strings, it might > > require some large changes. > > Perhaps stored procedures might help too....
I doubt it'll do much difference - most of the work done is very simple queries, from what I can tell. Stored procs genreally help when you have either complex queries/logic, or when you can use them to limit the amount of data sent over the write. I'm not sure either of those would apply to Bacula. But I haven't digged into the details :-) //Magnus ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
