fix

Author: digoal

201702/20170203_01.md

@@ -86,6 +86,16 @@ Based on ideas from Alexander Korotkov's fast scan patch.
 
 当某个条件比较罕见，而另一个条件很常见时，有立竿见影的效果。（也就是说一个有很多行记录满足条件，另一个则只有少量记录满足条件）  
 
+例子(posting list/tree最小的先扫描，所以直接跳过若干ctid的扫描)  
+  
+![pic](20170203_01_pic_004.jpg)  
+  
+![pic](20170203_01_pic_001.jpg)  
+  
+![pic](20170203_01_pic_002.jpg)  
+  
+![pic](20170203_01_pic_003.jpg)  
+  
 2\. 依旧是multi-key的优化，优化点和1类似，对于所有tid都更小的posting list segments，连decoding都不做。  
 
 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=25b1dafab63f465a65c63b26834dc18857f0fa0c  
@@ -253,6 +263,46 @@ create index idx3 on t1 using gin (id, c1);
 
 select ? from t1 where id=? and c1 @> ....;
 ```  
+  
+## 参考
+[GIN in 9.4 and further](20170203_01_pdf_001.pdf)  
+  
+https://www.postgresql.org/docs/current/static/indexes-bitmap-scans.html  
+  
+https://www.postgresql.org/docs/current/static/indexes-multicolumn.html  
+  
+```
+A multicolumn B-tree index can be used with query conditions that involve any subset of the index's columns, but the index is most efficient when there are constraints on the leading (leftmost) columns. The exact rule is that equality constraints on leading columns, plus any inequality constraints on the first column that does not have an equality constraint, will be used to limit the portion of the index that is scanned. Constraints on columns to the right of these columns are checked in the index, so they save visits to the table proper, but they do not reduce the portion of the index that has to be scanned. For example, given an index on (a, b, c) and a query condition WHERE a = 5 AND b >= 42 AND c < 77, the index would have to be scanned from the first entry with a = 5 and b = 42 up through the last entry with a = 5. Index entries with c >= 77 would be skipped, but they'd still have to be scanned through. This index could in principle be used for queries that have constraints on b and/or c with no constraint on a — but the entire index would have to be scanned, so in most cases the planner would prefer a sequential table scan over using the index.
+
+A multicolumn GiST index can be used with query conditions that involve any subset of the index's columns. Conditions on additional columns restrict the entries returned by the index, but the condition on the first column is the most important one for determining how much of the index needs to be scanned. A GiST index will be relatively ineffective if its first column has only a few distinct values, even if there are many distinct values in additional columns.
+
+A multicolumn GIN index can be used with query conditions that involve any subset of the index's columns. Unlike B-tree or GiST, index search effectiveness is the same regardless of which index column(s) the query conditions use.
+```
+  
+https://www.postgresql.org/docs/devel/static/gin-implementation.html  
+  
+```
+Multicolumn GIN indexes are implemented by building a single B-tree over composite values (column number, key value). The key values for different columns can be of different types.
+```
+    
+src/backend/access/gin/README  
+  
+```
+* In a single-column index, a key tuple just contains the key datum, but
+in a multi-column index, a key tuple contains the pair (column number,
+key datum) where the column number is stored as an int2.  This is needed
+to support different key data types in different columns.  This much of
+the tuple is built by index_form_tuple according to the usual rules.
+The column number (if present) can never be null, but the key datum can
+be, in which case a null bitmap is present as usual.  (As usual for index
+tuples, the size of the null bitmap is fixed at INDEX_MAX_KEYS.)
+```
+  
+backend/access/gin/ginentrypage.c:      itup = index_form_tuple(ginstate->tupdesc[attnum - 1], datums, isnull);  
+  
+backend/access/nbtree/nbtree.c: itup = index_form_tuple(RelationGetDescr(rel), values, isnull);  
+  
+backend/access/common/indextuple.c:index_form_tuple(TupleDesc tupleDescriptor,    
 
 [Count](http://info.flagcounter.com/h9V1)