in reply to Re^2: Remote database and process
in thread Remote database and process

Then I would suggest you look at the mysql --quick command & option.

If you combine that with the mysql < script.sql > results., the memory usage by the local process will be minimal and the results will be retrieved and filed far more quickly than you will ever achieve with Perl & DBI. (Sorry if that offends anyone, but it is true!)

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP an inspiration; A true Folk's Guy

Replies are listed 'Best First'.
Re^4: Remote database and process
by Anonymous Monk on Jun 07, 2010 at 08:44 UTC
    (Sorry if that offends anyone, but it is true!)

    Disclaimers are so offensive

    :p

[reply]

      I've never laimed any discs!

      Well. There was that one I used as a coaster but ...

[reply]
Re^4: Remote database and process
by ashokpj (Hermit) on Jun 07, 2010 at 08:05 UTC
    Hi, I wonder if POE::Component::DBIAgent - POE Component for running asynchronous DBI calls is efficient to do? Please sugguest.
[reply]

      If a single DBI query returns (and caches) sufficient data to cause you to have memory problems in a stand-alone process; running multiple concurrent queries via POE (or anything else isn't going to prevent that problem from occuring.

      The --quick option of the mysql command is specifically designed to return query results row by row rather than accumulating them all in memory and returning them en-masse. Hence my suggestion to use that.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom