title: Why lucene doesn't require composite index, but relation database does?
body: <p>Lucene stores index for each field separetly. So when we perform query "fld1:a AND fld2:b" we iterate over Termdocs for first term and second term. This can't be faster. In case of database two separete indexes for fld1 and fld2 will work slow and only one will be used. In that case DB requres composite key for fld1 and fld2. </p>
  
  <p>My question is. Why Can't DB utilize Lucene index algorithm for executing Boolean queries if it as fast as DB index and dosn't requires different combinations of columns?</p>
  
  <p>Some details of Lucene Boolean Query search:
  It utilize interface <a href="http://lucene.apache.org/java/2_3_2/api/org/apache/lucene/index/TermDocs.html" rel="nofollow">TermDoc</a>. The main idea in using two methods <code>boolean skipTo(int)</code> and <code>boolean next()</code>. So it is doesn't depend on term order(popular or not popular term) because count of those method calls will be always as most infrequent term(due to skipTo method). So there are no need in hierarchical composite index, it will not bring any additional performance.</p>
  
  <pre><code>TermDocs t1 = searcher.docs(fld1:a);
  TermDocs t2 = searcher.docs(fld2:b); 
  int doc = -1;
  t1.next(); t2.next();
  while(t1.doc()!=-1 &amp;&amp; t2.doc()!=-1) {
  if(t1.doc()&lt;t2.doc()) {
    if(!t1.skipTo(t2.doc)) return;
  }
  if(t2.doc()&lt;t1.doc()) {
   if(!t2.skipTo(t1.doc)) return;
  }
  if(t1.doc()==t2.doc()) {
  println("found doc:"+t1.doc());
  t1.next()
  }
  }
  </code></pre>