But I still think that it is feasible to make big_query() intelligent and pull in the rest of the stream, as soon as it notices another big_query() being started on the same connection.
I was hoping Per would respond to this, since he's the one who's having trouble with it. Anyway, as far as I've understood that might not be good enough since it can keep the tables locked for too long. I.e. it can be important that the whole response is read quickly if there are other users of the database. And having a pike loop that reads it all in before it's used would create the same kind of bulky pike structures that query() suffers from.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-09-30 22:49: Subject: Re: MySQL big_query in 7.7
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
big_query: A variant of query() that still is nonstreaming. I.e. streaming_query: Like big_query but guaranteed to stream if it
Sounds like a plan. But I still think that it is feasible to make big_query() intelligent and pull in the rest of the stream, as soon as it notices another big_query() being started on the same connection. I.e. it should not be a large performance hit, yet still offer all the advantages, and be compatible to existing applications. It basically makes a runtime decision if streaming is possible or not.
While at it, we could also consider generalizing the big_typed_query interface that the oracle module provides:
big_typed_query: Like big_query but doesn't convert everything to
No argument here.
Sincerely, srb@cuci.nl Stephen R. van den Berg (AKA BuGless). Gravity is running out! Conserve gravity: walk with a light step, use tape, magnets or glue instead of paperweights, avoid showers... take baths instead.
/ Brevbäraren