Re: WIP: Covering + unique indexes.
От | Peter Geoghegan |
---|---|
Тема | Re: WIP: Covering + unique indexes. |
Дата | |
Msg-id | CAM3SWZQZmo-Si1QGmmqwHTTOO22SNFVjLnjLB=adXBmrTGSRFg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WIP: Covering + unique indexes. (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>) |
Ответы |
Re: WIP: Covering + unique indexes.
|
Список | pgsql-hackers |
On Wed, Apr 6, 2016 at 6:15 AM, Anastasia Lubennikova <a.lubennikova@postgrespro.ru> wrote: >> * I would like to see index_reform_tuple() assert that the new, >> truncated index tuple is definitely <= the original (I worry about the >> 1/3 page restriction issue). Maybe you should also change the name of >> index_reform_tuple(), per David. > > Is it possible that the new tuple, containing less attributes than the old > one, will have a greater size? > Maybe you can give an example? > I think that Assert(indnkeyatts <= indnatts); covers this kind of errors. I don't think it is possible, because you aren't e.g. making an attribute's value NULL where it wasn't NULL before (making the IndexTuple contain a NULL bitmap where it didn't before). But that's kind of subtle, and it certainly seems worth an assertion. It could change tomorrow, when someone optimizes heap_deform_tuple(), which has been proposed more than once. Personally, I like documenting assertions, and will sometimes write assertions that the compiler could easily optimize away. Maybe going *that* far is more a matter of personal style, but I think an assertion about the new index tuple size being <= the old one is just a good idea. It's not about a problem in your code at all. > I do not mind to rename this function, but what name would be better? > index_truncate_tuple()? That seems better, yes. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: