Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x
Date
Msg-id 1564.1496176732@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] [PATCH] relocation truncated to fit: citus build failure on s390x  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] [PATCH] relocation truncated to fit: citus buildfailure on s390x  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] [PATCH] relocation truncated to fit: citus buildfailure on s390x  (Christoph Berg <myon@debian.org>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: [HACKERS] syscache entries out of order
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] ECPG: pg_type.h file is not synced