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. Rory -- Rory Campbell-Lange r...@campbell-lange.net ------------------------------------------------------------------------------ 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
