Time to read pg_hba.conf (Re: [PATCHES] [PATCH] Patch to make...) - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Time to read pg_hba.conf (Re: [PATCHES] [PATCH] Patch to make...)
Date
Msg-id Pine.LNX.4.30.0107102110540.677-100000@peter.localdomain
Whole thread Raw
Responses Re: Time to read pg_hba.conf (Re: [PATCHES] [PATCH] Patch to make...)
List pgsql-hackers
Tom Lane writes:

> Since pg_hba.conf is re-read on every connection, I've always thought
> it was pretty bogus to bulk it up with that much internal documentation.
> I've not tried to measure how much time it takes the postmaster to skip
> over those 200 comment lines, but it can't be completely negligible.

I've run a simplistic test for this.  I've let psql start 10000 times
sequentially and timed the backend startup.  All times are wall clock
(gettimeofday).  The first checkpoint is after the accept(), the second
before the backend loop begins.  The machine had a load average of 1.00 to
1.50 and wasn't running anything else besides "infrastructure".

default pg_hba.conf
count |   min    |   max    |     avg      |       stddev
-------+----------+----------+--------------+---------------------10000 | 0.024667 | 0.060208 | 0.0298723081 |
0.00746411804719077

pg_hba.conf, all comments removed
count |   min    |   max   |        avg         |       stddev
-------+----------+---------+--------------------+---------------------10000 | 0.022364 | 0.05946 | 0.0262477744000001
|0.00570493964559965
 

So we're looking at a possible 12% win.  I suggest we remove the comments
and direct the user to the Admin Guide.

Btw., in case someone wants to go optimizing, more than 75% of the backend
startup time is spent in InitPostgres():
count |   min   |   max    |     avg      |       stddev
-------+---------+----------+--------------+---------------------10000 | 0.01953 | 0.368216 | 0.0222271679 |
0.00629838985852663

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter



pgsql-hackers by date:

Previous
From: ncm@zembu.com (Nathan Myers)
Date:
Subject: Re: AW: pg_index.indislossy
Next
From: Peter Eisentraut
Date:
Subject: Re: grant and SQL92