<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 07 Mar 2014, at 16:21, Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>> wrote:</div><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br><blockquote type="cite">Is it possible to use an index for x-cache joins with linear index update time and query?<br></blockquote><br>Index update cost is not linear but LogN: approximates to a constant<br>cost. And we could cut this constant by 4 orders of magnitude if only<br>I could safely differentiate between a put of a new entry vs. an<br>update -> something which we'll need to brainstorm about.<br><br>Query time is also significantly sub-linear in practice, but specifics<br>will vary on the query type.<br><br>Yes you could use indexes to improve x-cache joins, but you'll need an<br>additional engine to coordinate that correctly, not least to manage<br>data size buffers; essentially I think you'd need Teiid.<br><br></div></blockquote><div><br></div><div>I think Mircea means implementing joins across different caches if the foreign key is indexed.</div><div><br></div><div>It would basically require N index seek (N being the number of fk value on your left hand side) per join and some aggregation engine to link the elements matching from the two side.</div><div>So N^M</div><div><br></div><div>M= # of joins</div><div>N= # of distinct FK involved</div><div><br></div><div>Does that reasoning sound right?</div></div></body></html>