Use CompactAttribute more often, when possible
| От | David Rowley |
|---|---|
| Тема | Use CompactAttribute more often, when possible |
| Дата | |
| Msg-id | CAApHDvrMy90o1Lgkt31F82tcSuwRFHq3vyGewSRN=-QuSEEvyQ@mail.gmail.com обсуждение исходный текст |
| Ответы |
Re: Use CompactAttribute more often, when possible
Re: Use CompactAttribute more often, when possible Re: Use CompactAttribute more often, when possible |
| Список | pgsql-hackers |
5983a4cff added CompactAttribute to TupleDesc to allow commonly accessed fields from the FormData_pg_attribute array to be accessed more quickly by having to load fewer cachelines from memory. That commit also went around and changed many locations to use CompactAttribute, but not all locations. The attached aims to adjust the remaining locations that I'm comfortable changing. I've avoided doing anything in tablecmds.c as that's where TupleDescs tend to get changed and I think there's a bit of undue risk using CompactAttribute there, just in case it gets accessed after the TupleDesc is changed and before flushing the pending changes to CompactAttribute in populate_compact_attribute(). Also, I'm aware that the code around the population of the CompactAttribute has changed a bit since it was added. attgenerated no longer mirrors its equivalent pg_attribute column. If that was made to mirror that column again, then there are a few extra locations that could be made to use CompactAttribute. There's also some more complexity around CompactAttribute.attnotnull that's crept in. I think I roughly understand the need for that, but the intent of CompactAttribute mirroring commonly used pg_attribute fields is made no longer true by those changes as it now contains extra information that's unavailable in pg_attribute. It'd be nice if pg_attribute also had the various additional states of attnotnull that CompactAttribute now has. </rant> I don't think the attached is very interesting to look at, but l'll leave it here for a bit just in case anyone wants to look. Otherwise, I plan to just treat it as a follow-up of 5983a4cff. David
Вложения
В списке pgsql-hackers по дате отправления: