>>>>> On Tue, 9 Sep 2008 13:12:01 -0400, Bill Moran said: > > In response to Martin Simmons <[EMAIL PROTECTED]>: > > > For a start, Path.PathId is a primary key and the > > suggested new index on File.PathId must have sped up the SELECT, not the > > DELETEs. > > While you bring up a valid point about the select possibly being a > larger problem than the delete, it doesn't change my overall premise: > that tweaking the SQL to make it faster on one platform might make it > slower on another.
Agreed. > > Secondly, unless the Path table is very much out of date relative to > > the File table, you would not expect to find a huge number of orphaned path > > records. > > Define "huge"? is 336046 huge? I don't consider it to be all that > large when you consider a path table of almost 1 million, a file > table of over 43 million and a filename table of over 11 million. I would define huge as something that takes too long to delete, maybe more than a few hours. The OP was talking about days, which is definitely too long. 336046 out of 1 million (i.e. > 1/3) is actually a surprisingly large ratio to me, unless you've not run dbcheck for a long time. __Martin ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
