Re: Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

* Amit Kapila (amit(dot)kapila(at)huawei(dot)com) wrote:
> Below are some points in my mind due to which I have supported/implemented
> one-file-all-setting approach:
> a. I had heard quite a few times that Postgres has lot of files (each
> relation has separate file) as compare to Oracle.
> Users feel that Oracle's table space approach is better.

This is completely unrelated to this discussion, imv.

> b. While server start/Sighup, we needs to open/read/close each file
> separately which in-itself seems to be overhead.

I also don't think performance of this particular operation should be a
high priority.

> I believe what Greg Stark has said in his below mail link is the more
> appropriate way and the current patch has done that way.
> http://www.postgresql.org/message-id/CAM-w4HP7=a2VowyJUD0CAZL5b8FsaHymdQeouL
> udSOhdnCw_zg(at)mail(dot)gmail(dot)com

He doesn't actually provide any reasoning for it. That said, I've not
heard any particularly good reason for having a setting per file either.
This is an internal-to-PG data file and we should really implement it in
whichever way makes the most sense for us. My general feeling is that
one file is simpler and sufficient for the postgresql.conf-like
parameters, but I wonder what we're going to do for pg_hba/pg_ident.
Those would be good to have multiple files for because (as we saw with
pg_authid) they could get quite large because they can have per-user
entries in them and rewriting a large file for every change would be
quite painful.

> Also when other commercial database (Oracle) can do it with single file,
> users will try to compare with it.

To make it clear- this isn't justification for this design. Also, the
notion that Oracle's *configuration* is all done with a *single-file*
is.. laughable.

Thanks,

Stephen