I wrote:
> Very possibly true, but I wish we had some hard facts and not just
> guesses.
As a simple but on-point test, I compared sizes of postgres_fdw.so
built with -fpic and -fPIC. I no longer have access to a wide variety
of weird architectures, but on what I do have in my office:
x86_64, RHEL6:
-fpic:
text data bss dec hex filename
85467 2632 64 88163 15863 postgres_fdw.so
-fPIC:
text data bss dec hex filename
85467 2632 64 88163 15863 postgres_fdw.so
This seems to confirm Andres' opinion that it makes no difference on
x86_64.
PPC, FreeBSD 10.3:
-fpic:
text data bss dec hex filename
86638 420 32 87090 15432 postgres_fdw.so
-fPIC:
text data bss dec hex filename
86474 1860 32 88366 1592e postgres_fdw.so
that's a 1.47% penalty
PPC, NetBSD 5.1.5:
-fpic:
text data bss dec hex filename
81880 420 56 82356 141b4 postgres_fdw.so
-fPIC:
text data bss dec hex filename
81688 2044 56 83788 1474c postgres_fdw.so
that's a 1.74% penalty
HPPA, HPUX 10.20:
-fpic:
text data bss dec hex filename
97253 17296 8 114557 1bf7d postgres_fdw.sl
-fPIC:
text data bss dec hex filename
102629 17320 8 119957 1d495 postgres_fdw.sl
that's a 4.7% penalty
It's somewhat noteworthy that the PPC builds show a large increase in data
segment size. That likely corresponds to relocatable pointer fields that
have to be massaged by the dynamic linker during shlib load. Thus one
could speculate that shlib load might be noticeably slower with -fPIC,
at least on PPC. But people rarely complain about the speed of that
anyway, so it's unlikely to be worth worrying about.
It'd be interesting if people could gather similar numbers on other
platforms of more real-world relevance, such as ppc64. But based on
this small sample, I wouldn't object to just going to -fPIC across
the board.
regards, tom lane