unnecessary overhead on process startup

From: Frank Joerdens <frank(at)joerdens(dot)de>
To: pgsql-general(at)postgresql(dot)org
Subject: unnecessary overhead on process startup
Date: 2001-01-01 14:45:09
Message-ID: 3A5097F5.A3ED7563@joerdens.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I just noticed that the default order in the PATH to the postgres executable may introduce
some unnecessary overhead when starting a process:

postmaster: ServerLoop:^I^Ihandling reading 4
postmaster: ServerLoop:^I^Ihandling reading 4
postmaster: ServerLoop:^I^Ihandling writing 4
postmaster: BackendStartup: pid 15909 user nobody db crewscout socket 4
postmaster child[15909]: starting with (postgres -d2 -S 2000 -v131072 -p crewscout )
FindExec: searching PATH ...
ValidateBinary: can't stat "/bin/postgres"
ValidateBinary: can't stat "/usr/bin/postgres"
ValidateBinary: can't stat "/usr/local/bin/postgres"
ValidateBinary: can't stat "/usr/bin/X11/postgres"
ValidateBinary: can't stat "/usr/X11R6/bin/postgres"
ValidateBinary: can't stat "/usr/local/sbin/postgres"
FindExec: found "/usr/local/pgsql/bin/postgres" using PATH
DEBUG: connection: host=[local] user=nobody database=crewscout

The OS is Linux. I don't know whether this is really significant at all (because I don't
know how exactly the OS does the searching and whether the order really matters that
much), but I changed the PATH in .bash_profile for the user postgres, like

PATH=$HOME/bin:$PATH

so that /usr/local/pgsql/bin/postgres is searched first, and I get

logger: postmaster: ServerLoop:^I^Ihandling reading 4
logger: postmaster: ServerLoop:^I^Ihandling reading 4
logger: postmaster: ServerLoop:^I^Ihandling writing 4
logger: postmaster: BackendStartup: pid 15967 user nobody db crewscout socket 4
logger: postmaster child[15967]: starting with (postgres -d2 -S 2000 -v131072 -p crewscout
)
logger: FindExec: searching PATH ...
logger: FindExec: found "/usr/local/pgsql/bin/postgres" using PATH
logger: DEBUG: connection: host=[local] user=nobody database=crewscout

which just _may_ be a little faster. Just thought it might be worth mentioning (maybe this
is really old news).

Regards, Frank

Browse pgsql-general by date

  From Date Subject
Next Message Matt Beauregard 2001-01-02 05:58:21 data change violation inside transaction
Previous Message Frank Joerdens 2001-01-01 14:05:30 Re: pg_dump segfaults with -z on 6.4