Re: Bitmap index AM
От | Victor Yegorov |
---|---|
Тема | Re: Bitmap index AM |
Дата | |
Msg-id | 20050704231502.GB8828@mits.lv обсуждение исходный текст |
Ответ на | Bitmap index AM (Victor Yegorov <viy@mits.lv>) |
Ответы |
Re: Bitmap index AM
|
Список | pgsql-patches |
I've managed to fix all bugs I've met so far. Attached is an updated patch. Comments: o README should be updated to reflect the changes I've done recently; o I'm still haven't tested ammarkpos and amrestrpos functions --- planner is choosing Nested Loop all the time and my knowledge of query tuning isn't that good to force Merge Join usage; o The main reason no space is freed during ambulkdelete is that that would make inserts and updates really slow. It would take really small amount of time to determine free slot in the List-of-CTIDs, but then I'd have to read and check the majority of bitmap storage pages, as there is no easy way to determine page where bit at given position belongs (or I don't see it at the moment). The cause --- page contains both, plain and compressed blocks. And the number of tuples one page of bitmap storage covers may significantly vary, thus I have to check each page to find the one where newly inserted tuple should belong. And such search should be done for each value in the indexed attributes domain. But I'm willing to discuss any opinions and waiting for the feedback. Maybe we can find a good compromise here. Thanks! -- Victor Y. Yegorov
Вложения
В списке pgsql-patches по дате отправления: