Re: Proposal for Null Bitmap Optimization(for TrailingNULLs)
От | Gregory Stark |
---|---|
Тема | Re: Proposal for Null Bitmap Optimization(for TrailingNULLs) |
Дата | |
Msg-id | 87lk7rjz4c.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Proposal for Null Bitmap Optimization(for TrailingNULLs) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Proposal for Null Bitmap Optimization(for TrailingNULLs)
|
Список | pgsql-hackers |
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > "Gokulakannan Somasundaram" <gokul007@gmail.com> writes: >> I have currently completed the following >> a) If there are only trailing nulls in the heap, no null-bitmap gets stored >> b) If there are trailing nulls in addition to nulls inbetween values in the >> heap, then the trailing nulls are not added to the null-bitmap. I wouldn't >> have done it, but it came almost free of cost >> c) If there are only trailing nulls in the index, no null-bitmap gets stored > >> The index part gave some issues and i hope i have fixed it. > > I doubt you have fixed it; I doubt it's *possible* to fix it without > significant rejiggering of IndexTuple representation. The problem is > that IndexTuple lacks a number-of-fields field, so there is no place > to indicate how many null bitmap bits you have actually stored. > I would suggest forgetting that part and submitting the part that > has some chance of getting accepted. I suspect there's also an awkward case that *does* need to handled when you insert a tuple which has a null column which you're leaving out of the tuple but which appears in an index. You would have to make sure that the index tuple has that datum listed as NULL even though it's entirely missing from the heap tuple. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning
В списке pgsql-hackers по дате отправления: