Daniel Bausch wrote: > I am going to implement a simple kind of "encoded bitmap indexes" (EBI).
> I thought, it could be a good idea to base my work on the long proposed > on-disk bitmap index implementation. Regarding to the wiki, you, Jonah > and Simon, were the last devs that touched this thing. Unfortunately I > could not find the patch representing your state of that work. I could > only capture the development history up to Gianni Ciolli & Gabriele > Bartolini from the old pgsql-patches archives. Other people involved > were Jie Zhang, Gavin Sherry, Heikki Linnakangas, and Leonardo F. Are > you and the others still interested in getting this into PG? A rebase > of the most current bitmap index implementation onto master HEAD will be > the first 'byproduct' that I am going to deliver back to you. > > 1. Is anyone working on this currently? > 2. Who has got the most current source code? > 3. Is there a git of that or will I need to reconstruct the history from > the patches I collected? It seems like you did not get any answers from any of the people you mentioned ... The latest version of the patch I found is http://archives.postgresql.org/pgsql-patches/2006-12/msg00015.php So that's probably the best you can get. I want to encourage you to work on this. You'd have to come up with a sound concept and discuss it on this list, and it would be helpful to have some draft patch for git master that can be used as a basis for discussion. Expect to meet some resistance. Nobody will want the extra code and complexity unless you can show suffitient benefits. One concern that came up in previous discussions is that bitmap indexes are only useful for columns with low cardinality, and in that case the result will likely be a significant portion of the table anyway and a sequential scan would be faster. I think that this is less true if you have more conditions, and this is supposedly the case where encoded bitmap indexes work better anyway. Another criticism I can imagine is that PostgreSQL already supports a bitmap index scan of b-tree indexes, so you would have to show that on-disk bitmap indexes outperform that in realistic scenarios. This has probably become more difficult with the recently introduced index-only scan for b-tree indexes, which is particularly helpful in data warehouse scenarios. So you'd have to run some performance tests against a draft implementation to get people convinced that it is worth the effort. Supporting index-only scans Would probably give you an edge. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers