On 8/4/2010 6:28 AM, Rory Campbell-Lange wrote:
> 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.

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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users