- From: Pablo Castro <Pablo.Castro@microsoft.com>
- Date: Wed, 15 Dec 2010 00:19:32 +0000
- To: Jonas Sicking <jonas@sicking.cc>, Jeremy Orlow <jorlow@chromium.org>
- CC: Bjoern Hoehrmann <derhoermi@gmx.net>, "public-webapps@w3.org" <public-webapps@w3.org>
From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Jonas Sicking Sent: Friday, December 10, 2010 1:42 PM >> On Fri, Dec 10, 2010 at 7:32 AM, Jeremy Orlow <jorlow@chromium.org> wrote: >> > Any more thoughts on this? >> >> I don't feel strongly one way or another. Implementation wise I don't >> really understand why implementations couldn't use keys of unlimited >> size. I wouldn't imagine implementations would want to use fixed-size >> allocations for every key anyway, right (which would be a strong >> reason to keep maximum size down). I don't have a very strong opinion either. I don't quite agree with the guideline of "having something working slowly is better than not working at all"...as having something not work at all sometimes may help developers hit a wall and think differently about their approach for a given problem. That said, if folks think this is an instance where we're better off not having a limit I'm fine with it. >> Pablo, do you know why the back ends you were looking at had such >> relatively low limits? Mostly an implementation thing. Keys (and all other non-blob columns) typically need to fit in a page. Predictable perf is also nice (no linked lists, high density/locality, etc.), but not as fundamental as page size. -pablo
Received on Wednesday, 15 December 2010 00:20:18 UTC