Re: Unimpressed with pg_attribute_always_inline
Вложения
В списке pgsql-hackers по дате отправления:
| От | Thomas Munro |
|---|---|
| Тема | Re: Unimpressed with pg_attribute_always_inline |
| Дата | |
| Msg-id | CAEepm=2iTKvbebiK3CdoczQk4_FfDt1EeU4c+nGE340JH7gQ0g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Unimpressed with pg_attribute_always_inline (Thomas Munro <thomas.munro@enterprisedb.com>) |
| Ответы |
Re: Unimpressed with pg_attribute_always_inline
|
| Список | pgsql-hackers |
On Tue, Jan 2, 2018 at 4:58 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Tue, Jan 2, 2018 at 4:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> gaur | nodeHashjoin.c:167: warning: `always_inline' attribute directive ignored >> mastodon | .\src\backend\executor\nodeHashjoin.c(165): warning C4141: 'inline' : used more than once > > 1. MSVC doesn't like you to say both "__forceinline" and "inline". > > 2. GCC 2.95.3 doesn't understand always_inline. From a quick look at > archived manuals, it seems that that attribute arrived in 3.1. Here is one way to fix those warnings. Thoughts? >> Therefore, I think that pg_attribute_always_inline is not merely >> useless but actively bad, and should be removed. How about a macro PG_NOINLINE, which, if defined, inhibits this? Or I could give up this strategy and maintain two separate very similar functions, ExecHashJoin and ExecParallelHashJoin. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера