From: Martin S. <ma...@li...> - 2007-03-22 20:35:00
|
>>>>> On Wed, 21 Mar 2007 17:45:02 +0100, Kern Sibbald said: > > On Wednesday 21 March 2007 16:58, Alan Brown wrote: > > On Wed, 21 Mar 2007, Marc Cousin wrote: > > > > > I think I haven't explained the memory issue correctly : > > > > I realise it's an issue for large selects, but in the case given: > > > > > > > > The example Kern gave is : > > > > > > "SELECT JobMedia.JobMediaId,Job.JobId FROM JobMedia " > > > "LEFT OUTER JOIN Job ON (JobMedia.JobId=Job.JobId) " > > > "WHERE Job.JobId IS NULL LIMIT 300000"; > > > > > > and it only fails if I remove the "LIMIT 3000000". > > > > Would be better solved with: > > > > "SELECT COUNT(*) FROM JobMedia " > > "LEFT OUTER JOIN Job ON (JobMedia.JobId=Job.JobId) " > > "WHERE Job.JobId IS NULL "; > > > > Because the very next lines in dbcheck simply count the resulting lines of > > output. > > I've taken another look at the code, and it is not nearly as simple as you > suggest. Bacula does print a count, but if the user requests the items to be > printered, Bacula prints them. Assuming that the user wants to see the > records before deleting them, your suggestion would complicate the code a > lot, and require the SQL engine to pass through similar SELECTs twice. The user probably won't want to see 300000 of them :-) Maybe this is another use for a temporary table, to contain the rows until the user decides? __Martin |