>
> Some other problems I see with GUCs
>
> * It's not possible to set one parameter depending upon the setting of
> another.
>
To me this is more critical.. Most people I have seen will increase one
or few but not all parameters related to memory which can result in loss
of performance and productivity in figuring out.
What happened to AvailRAM setting and base all memory gucs on that.
Ideally PostgreSQL should only create one big memory pool and allow all
other variables to change runtime via dba or some tuner process or
customized application as long as total is less than the allocated
shared_memory and local_memory settings. (This will also reduce the need
of restarting Postgres if a value needs to be changed)
-Jignesh
> * It's always unclear which GUCs can be changed, and when. That is much
> more infrequently understood than the meaning of them.
>
> * We should rename effective_cache_size to something that doesn't sound
> like it does what shared_buffers does
>
> * There is no config verification utility, so if you make a change and
> then try to restart and it won't, you are in trouble.
>
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment