rutledge.50 ha scritto:
Hi, thanks Marcello :)
I finally figured it out by painfully following 10 sets of data through
the process.
First, this was causing two problems:
#now cycle through result set in next query
foreach $myhsid (@hsid)
{
$myhport = pop(@hport);
$myhmac = pop(@hmac);
print "trying $myhsid $myhport $myhmac\n";
Foreach was only iterating through UNIQUE instances of $myhsid. So the
whole dataset was not used. Also I was pop'ing two values from the set,
while foreach was iterating through the other array TOP DOWN, where pop
goes BOTTOM UP. D'oh!
So I ended up with something like:
for ([EMAIL PROTECTED]; $count !=0; $count--) {
$myhsid=pop(@hsid);
So now I get the count from @hsid, and then pop all arrays so the
datasets stay matched :)
Unfortunately the database is huge. When I left work Friday my script
was still running after about 30 hours. It looks like 'order by hdate
desc limit 1' is a LOT SLOWER than 'order by hdate limit 1' for some
reason. Must be internal MySQL stuff...
Just some thoughts as I read this:
1) it seems to me you are reading the whole dataset into @hsid, @hport,
etc. arrays. If the database is huge, maybe the machine is swapping
heavily, thus increasing the processing time of the script...
2) maybe you have an index on hdate but not on the hdate, desc couple.
Thanks,
Lincoln
Prego
Marcello
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>