MySQL question (was Re: [HACKERS] What about LIMIT in SELECT ?)
От | Jeff Hoffmann |
---|---|
Тема | MySQL question (was Re: [HACKERS] What about LIMIT in SELECT ?) |
Дата | |
Msg-id | 00c801bdf7a7$3489b100$c525c4ce@go-to-jail.remapcorp.com обсуждение исходный текст |
Список | pgsql-hackers |
>On Tue, 13 Oct 1998, Bruce Momjian wrote: > >> My guess in a web application is that the transaction is started for >> every new page, so you can't have transactions spanning SQL sessions. >> >> LIMIT theoretically would allow you to start up where you left off. slightly off topic question, but how would this work? by doing an order by and knowing the last record? or is this handled automatically in MySQL? > >************ EXACTLY !-) >Plus, it could also be used to limit bogus-run-away queries. i'm not really following this thread too closely (i'm reading but not always thinking while i read) so i probably missed some things, but it seems to me the query limit env. variable hack is a *good thing* (i would use it, at least -- specifically to eliminate runaway queries, not so much to limit the # of matches) and the cursor approach would be the *right way* but not always the easiest way (in # of steps) or fastest way (because of the order by/sort business -- i've been using cursors in web apps for a while now, so i never noticed that this causes things to get ugly or think about why). i can understand things getting ugly with joins and sorting, but on a plain, single table select with no indexes (or even with indexes), which is apparently the target of the todo item, i still don't get the difference. you'd still be stuck scanning, which i would think would be the time consuming part. i guess that's why i'm just a lurker and not really a hacker, though.
В списке pgsql-hackers по дате отправления: