On 03/08/10, Dan Langille (dan AT langille DOT 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
rory AT campbell-lange DOT 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users