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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers