Re: [HACKERS] Atomics for heap_parallelscan_nextpage()
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Atomics for heap_parallelscan_nextpage() |
Дата | |
Msg-id | 31090.1502905468@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Atomics for heap_parallelscan_nextpage() (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] Atomics for heap_parallelscan_nextpage()
Re: [HACKERS] Atomics for heap_parallelscan_nextpage() |
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > Don't think we require BUFFERALIGN - MAXALIGN ought to be > sufficient. Uh, see my other message just now. > The use of BUFFERALIGN presumably is to space out things > into different cachelines, but that doesn't really seem to be important > with this. Then we can just avoid defining the new macro... I was feeling a bit uncomfortable with the BUFFERALIGN_DOWN() for a different reason: if the caller has specified the exact amount of space it needs, having shm_toc_create discard some could lead to an unexpected failure. I wonder whether maybe shm_toc_create should just error out if the number it's handed isn't aligned already. >> + return BUFFERALIGN( >> + add_size(offsetof(shm_toc, toc_entry), >> + add_size(mul_size(e->number_of_keys, sizeof(shm_toc_entry)), >> + e->space_for_chunks))); > I think splitting this into separate statements would be better. +1, it was too complicated already. regards, tom lane
В списке pgsql-hackers по дате отправления: