Sinisa Milivojevic wrote:
>
> Hi!
>
> With :
>
> select * from table;
>
> queries MySQL returns results immediately.
>
> Any problem that you experience might come only from poor build, some
> OS bug or some wrong settings.
Thanks for the reply! That's good to know at least. I really didn't
know
if anything was wrong or not.
I've been looking through the docs and the list for a few days, but it's
tricky when you don't really know what to look for (searching for
stuff like "select" and "pause" doesn't help much ;-). However, I
think I finally stumbled upon at least part of my problem... It's
"mysql_store_result" vs. "mysql_use_result"!
Since both Perl's DBI and the mysql command use "mysql_store_result" by
default, all rows are buffered up before being returned - the more rows
the longer the delay. Informix behaves more like "mysql_use_result"
where results are returned as they are found.
The other problem is the delay when closing a select early. From what I
gather it seems like it's not possible to abort a select without first
reading all the rows. I'm guessing the mysql client and Perl DBI both
hide this by just doing the equivalent of sending what remains to
/dev/null (hence the delay).
I guess it's not really a problem now that I know what to expect. I
just have to remember to include limits on all my selects. It's just a
bit of a re-think since until recently, Informix had no statement like
LIMIT and it's normal to simply close the cursor (finish() under DBI)
once you've found what you're after.
Thanks,
S. Lemmon
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
