Re: Filter ::Handle segfaults 5.8.1

in reply to Filter ::Handle segfaults 5.8.1

Not that this has anything to do with your question and it sounds like ysth has pointed you in the right direction. I was just curious to know why your run with DBI calls took 12 days? I realize you time is probably short, I was just curious what DBMS you were using.

STH

Comment on Re: Filter ::Handle segfaults 5.8.1

Replies are listed 'Best First'.
Re: Re: Filter ::Handle segfaults 5.8.1 by leriksen (Curate) on Nov 17, 2003 at 23:19 UTC
ok, well the full run took 12 days with about 200,000 customer documents, so it wasn't one DBI call for 12 days - and it was a bug in the client data that triggerred it. We use Oracle, and as I said it was a first run, so while we fixed various issues and optimised our calls and code, we just let the test run continue for a benchmark. Some of the data sets are huge - before going live, we loaded >2Gb of historical data first. We now run our end-of-month prints in about 6 hours.	[reply]

Replies are listed 'Best First'.

Re: Re: Filter ::Handle segfaults 5.8.1
by leriksen (Curate) on Nov 17, 2003 at 23:19 UTC

ok, well the full run took 12 days with about 200,000 customer documents, so it wasn't one DBI call for 12 days - and it was a bug in the client data that triggerred it. We use Oracle, and as I said it was a first run, so while we fixed various issues and optimised our calls and code, we just let the test run continue for a benchmark. Some of the data sets are huge - before going live, we loaded >2Gb of historical data first. We now run our end-of-month prints in about 6 hours.

[reply]

In Section Seekers of Perl Wisdom