On 8/4/2010 6:28 AM, Rory Campbell-Lange wrote: > On 03/08/10, Dan Langille (d...@langille.org) wrote: >> On 8/3/2010 7:09 PM, Rory Campbell-Lange wrote: > >>> Yes, a batch insert is faster than a specfic insert, but the latter >>> should be done at the "written-to-tape" transaction time, and could be >>> done asynchronously, but in a transaction. >> >> So... don't use batch-insert. Go the single insert approach. I dare >> you. ;) > > Yes, I'm trying! I'm trying to do it properly by recompiling debian > stable backports and I'm running into library dependancy problems. > >>> This is a cludge (with an inefficient correlated subquery!) that could >>> easily miss paths which exist from previous, unrelated backups. A >>> continuous insert process against a job and mediaid simply wouldn't need >>> to do this. > >> If you want to patch it, we'll certainly look at it. > > I'll look at some of the post batch insert queries and look to optimise > them somewhat with our database development team in the next month. > >>> More native support for postgres would also allow, for instance, faster >>> and more powerful searching of catalogues for retrieves, rather than the >>> strange restore procedure required through bconsole. > >> Sure, it would. We're always looking for more people to take on the >> heavy lifting. > > Would it be helpful if we developed some proof-of-concept plpgsql > functions for searching catalogues? We could also do a bit of work on > UTF8 conversion/support.
I think stored procedures would be a good idea. That way, we could improve the functionality without changing the application. That said, we do not at present use stored procedures. We'd have to proceed carefully. -- Dan Langille - http://langille.org/ ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
