++ We'll should fix the problem (not just address the symptoms) if we can.
-jay On Sat, Mar 13, 2010 at 11:57 PM, Brian Moon <[email protected]> wrote: > Being primarily an application developer, I find it off putting that your > answer to this performance issue is to not let anyone ever do it. How do you > page through millions of rows then? We can't rely on auto_incremnt to always > get smaller when paging backwards. Not all data is date ordered. There is > not always a "where keyfield < 12345" available for these types of paging > scenarios. As a "good" developer, I don't do it because MySQL really, really > sucks at it. But, if there is a solution that can help large offsets, I > would think the ideals behind Drizzle would be to fix what MySQL screwed up, > not to disallow the feature. > > Shouldn't the first response to any problem be "Yes, that is a problem. How > can we fix the problem?" > > Brian. > -------- > http://brian.moonspot.net/ > > On 3/13/10 9:53 AM, Rob Wultsch wrote: >> >> On Sat, Mar 13, 2010 at 8:21 AM, MARK CALLAGHAN<[email protected]> >> wrote: >>> >>> On Sat, Mar 13, 2010 at 12:59 AM, Yuan Wang<[email protected]> >>> wrote: >>>> >>>> I think Drizzle should consider the ability to push down OFFSET to the >>>> storage engine. LIMIT/OFFSET is very common in most Web applications. >>>> Where there are lists, there are LIMIT/OFFSETs. For example, each user >>>> in Blog has a list of his articles. For this list could be long, we >>>> display it in pages, using the following SQL: >>> >>> This is a nice description of the problem and the feature that you >>> need. But I have been burned so many times in production by queries >>> with large offsets that I also want a feature to allow me to either >>> ban queries with an offset or set a limit on the max offset that can >>> be used. Of course, I can do that whether or not the optimization you >>> have requested is supported. >>> >>> Note that I don't write SQL, I just debug it and make it less slow and >>> this was written from experience -- >>> http://www.facebook.com/note.php?note_id=206034210932 >>> >> >> I have also seen this issue many times in production. Someone builds >> an app that allows pagination and the db is populated* with a >> significant amount of data. Later on a bot (I assume) discovers the >> app and tries to index the entire damn thing. This makes servers sad >> and no one likes a sad server. >> >> I agree that It would be useful to have a setting MAX_OFFSET like >> MAX_JOIN_SIZE (it would be awesome if that actually worked well, but >> that is another discussion). >> >> >> * In some contexts populated can be replaced with spammed to hell. > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
