Yes I envision the new strategy to be used for relatively small result sets. So I am not suggesting we replace DISJOINT with this behind the scenes. I'd like to leave it up to the users to pick (or maybe we can auto-choose based on the size of the main result set).
BTW paginated queries internally have a control limiting the size of the WHERE clause. It is hardcoded inside IncrementalFaultList and the value is 10000. So any extra large IN query will be broken to chunks. > How do these solutions work when the user tries to order the results on > something across a to-one join? Root query works the same with or without a disjoint prefetch, even if some joins overlap. Ordering of related (prefetched or otherwise) objects is controlled by the user. Andrus On Jan 30, 2012, at 2:54 PM, Aristedes Maniatis wrote: > On 30/01/12 10:43 PM, Andrus Adamchik wrote: >>> And does DISJOINT map to: >>> >>> SELECT * FROM ARTIST WHERE ARTIST_NAME LIKE 'X%' FETCH LIMIT 10; >>> SELECT * FROM PAINTING WHERE true; >> >> Effectively yes. With some extra nastiness like joins inherited from the >> parent query. >> >>> Are you proposing this new join type be: >>> >>> SELECT * FROM ARTIST WHERE ARTIST_NAME LIKE 'X%' FETCH LIMIT 10; >>> SELECT * FROM PAINTING WHERE ARTIST_ID IN (123, 124, ....) >> >> Yes. >> >> Andrus >> > > Some databases don't like the IN clause to be too big. 1024 entries seems to > be in my head about when we hit an error with MS SQL in the past. > > How do these solutions work when the user tries to order the results on > something across a to-one join? > > > > > > Ari > > > > -- > --------------------------> > Aristedes Maniatis > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >
