On 10 Feb 2006 at 6:58, Karl Hakimian wrote: > > I don't think COPY will be useful. > > I don't think I'm ready to give up on the copy command yet. The amount > of data in the filename and path tables is small compared to the file > table. If we created a copy command while updating the file and path > tables and then dumped the file updates via copy, that should be a > significant speed improvement.
Go for it! > > http://www.postgresql.org/docs/8.1/static/sql-copy.html > > > > The data we are adding to the database does not already exist. > > There's nothing to COPY. > > We should be able to created it from the spooled attributes. Note: you are proposing to change Bacula significantly. If you can do that without adversely affecting the other database choices, good. > > I think transactions are more important here. We need to look more > > closely at that. > > I believe transactions would help quite a bit. Seems to me I saw some > transaction code in bacula commented out. Does anyone know why it was > removed? If you have concurrent jobs, what happens when job #1 wants to add a file to the table, and job #2 wants to add the same file? How do you ensure that both transactions work without failure? -- Dan Langille : Software Developer looking for work my resume: http://www.freebsddiary.org/dan_langille.php ------------------------------------------------------- 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&kid=103432&bid=230486&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
