Re: CLUSTER and indisclustered
От | Tom Lane |
---|---|
Тема | Re: CLUSTER and indisclustered |
Дата | |
Msg-id | 15010.1028726802@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: CLUSTER and indisclustered (Hannu Krosing <hannu@tm.ee>) |
Ответы |
Re: CLUSTER and indisclustered
|
Список | pgsql-hackers |
Hannu Krosing <hannu@tm.ee> writes: > Now I remembered my original preference for page bitmaps (vs. tuple > bitmaps): one can't actually make good use of a bitmap of tuples because > there is no fixed tuples/page ratio and thus no way to quickly go from > bit position to actual tuple. You mention the same problem but propose a > different solution. > Using page bitmap, we will at least avoid fetching any unneeded pages - > essentially we will have a sequential scan over possibly interesting > pages. Right. One form of the "lossy compression" idea I suggested is to switch from a per-tuple bitmap to a per-page bitmap once the bitmap gets too large to work with. Again, one could imagine doing that only in denser areas of the bitmap. > But I guess that CLUSTER support for INSERT will not be touched for 7.3 > as will real bitmap indexes ;) All of this is far-future work I think. Adding a new scan type to the executor would probably be pretty localized, but the ramifications in the planner could be extensive --- especially if you want to do plans involving ANDed or ORed bitmaps. regards, tom lane
В списке pgsql-hackers по дате отправления: