Re: [DISCUSS] - QueryIndex selection

2014-06-18 Thread Jukka Zitting
Hi, On Wed, Jun 18, 2014 at 11:31 AM, Tommaso Teofili wrote: > 2014-06-18 16:02 GMT+02:00 Jukka Zitting : >> On Wed, Jun 18, 2014 at 4:26 AM, Tommaso Teofili >> wrote: >> > should we just return the number of estimated entries for the cost? >> >> Yes, that's what I think the contract should be.

Re: [DISCUSS] - QueryIndex selection

2014-06-18 Thread Tommaso Teofili
Hi, 2014-06-18 16:02 GMT+02:00 Jukka Zitting : > Hi, > > On Wed, Jun 18, 2014 at 4:26 AM, Tommaso Teofili > wrote: > > should we just return the number of estimated entries for the cost? > > Yes, that's what I think the contract should be. > ok, that's different from what Thomas suggests, right

Re: [DISCUSS] - QueryIndex selection

2014-06-18 Thread Tommaso Teofili
Hi, 2014-06-18 13:44 GMT+02:00 Thomas Mueller : > Hi, > > >>QueryIndex.getCost > > >my doubt is what > >this heuristic function to estimate the "traversed entries" should look > >like in general > > Relational databases typically know the number of entries in the index > (total indexed entries),

Re: [DISCUSS] - QueryIndex selection

2014-06-18 Thread Tommaso Teofili
ok, thanks Davide for the pointers. Regards, Tommaso 2014-06-18 13:36 GMT+02:00 Davide Giannella : > On 18/06/2014 10:26, Tommaso Teofili wrote: > > it would be ok for me to either deprecate it or improve the semantics > > of the cost calculation (e.g. explicitly introduce other metrics to be >

Re: [DISCUSS] - QueryIndex selection

2014-06-18 Thread Jukka Zitting
Hi, On Wed, Jun 18, 2014 at 7:44 AM, Thomas Mueller wrote: >>My other concern on this point is that it's not granted, in my opinion, >>that the index returning less entries would be the faster. > > Yes, it's not that much about less entries or more entries, it's about > lower or higher cost. If t

Re: [DISCUSS] - QueryIndex selection

2014-06-18 Thread Jukka Zitting
Hi, On Wed, Jun 18, 2014 at 4:26 AM, Tommaso Teofili wrote: > should we just return the number of estimated entries for the cost? Yes, that's what I think the contract should be. > My other concern on this point is that it's not granted, in my opinion, > that the index returning less entries wo

Re: [DISCUSS] - QueryIndex selection

2014-06-18 Thread Thomas Mueller
Hi, >>QueryIndex.getCost >my doubt is what >this heuristic function to estimate the "traversed entries" should look >like in general Relational databases typically know the number of entries in the index (total indexed entries), plus the selectivity of a column. See also http://www.akadia.com/se

Re: [DISCUSS] - QueryIndex selection

2014-06-18 Thread Davide Giannella
On 18/06/2014 10:26, Tommaso Teofili wrote: > it would be ok for me to either deprecate it or improve the semantics > of the cost calculation (e.g. explicitly introduce other metrics to be > taken into account in the cost calculation: local / remote index, With the IndexPlan.isDelayed() we instruc

QueryIndex, AdvancedQueryIndex and QueryIndexProvider

2014-06-18 Thread Davide Giannella
Good morning everyone, for OAK-1717 I was going to implement a new AdvancedQueryIndex. Unfortunately the QueryIndexProvider.getQueryIndexes() interface allows returning a list of QueryIndex. AdvancedQueryIndex is not a QueryIndex (does not extends) and for now I'm implementing the QueryIndex inte

Re: [DISCUSS] - QueryIndex selection

2014-06-18 Thread Tommaso Teofili
2014-06-04 9:36 GMT+02:00 Thomas Mueller : > Hi, > > QueryIndex.getCost: this is actually quite well documented (see the > Javadocs). But the implementations might not fully follow the contract :-) > this is probably just my opinion but the contract is not much clear; to me finding "the worst-cas