Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x |
| Дата | |
| Msg-id | 11629.1496153566@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: [HACKERS] [PATCH] relocation truncated to fit: citus buildfailure on s390x (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, May 29, 2017 at 3:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I wonder what the overhead is of using -fPIC when -fpic would be
>> sufficient.
> Do we have an idea how to measure the increased overhead? Just from
> reading the description, I'm guessing that the increased cost would
> happen when the extension calls back into core, but maybe that doesn't
> happen often enough to worry about?
My gut feeling is that it'd be a pretty distributed cost, because every
internal cross-reference in the .so (for instance, loading the address of
a string literal) would involve a bit more overhead to support a wider
offset field. An easy thing to look at would be how much the code expands
by. That might or might not be a good proxy for the runtime slowdown
percentage, but it seems like it ought to serve as a zero-order
approximation.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера