From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Dave Page <dpage(at)pgadmin(dot)org> |
Subject: | Re: Path separator |
Date: | 2009-04-07 13:44:58 |
Message-ID: | 49DB58DA.2040108@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander wrote:
>> The major stumbling block to doing either thing is not wishing to import
>> path.c into libpq. I think that the objection was partially code size
>> and partially namespace pollution (path.c doesn't use pg_ or similar
>> prefixes on its exported names). The latter is no longer a problem on
>> platforms that support exported-name filtering, but that isn't all of
>> them. Could we consider splitting path.c into two parts, that which we
>> want in libpq and that which we don't?
>
> On my system (linux), path.o is 5k. libpq.so is 157k. Is adding that
> size *really* a problem?
>
> Also, is there a chance that the linker is smart enough to actually
> remove the parts of path.o that aren't used in libpq completely, if it's
> not exported at all? (if the size does matter)
>
> If it is, sure, we could split it apart. But fairly large parts of it
> would be required by both. But I guess the number of symbols would be
> quite a bit smaller.
Answering myself here: the filesize for the "frontend only" part is
about 2k on this system.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2009-04-07 13:55:28 | Re: a few crazy ideas about hash joins |
Previous Message | Magnus Hagander | 2009-04-07 13:27:47 | Re: Path separator |