>> A good start might be to always OUTPUT memory parameters using the >> same base unit. > SHOW gives output that matches what you input.
Not for me it doesn't. portal=# show temp_buffers; temp_buffers -------------- 1024 (1 row) portal=# set temp_buffers = '16MB'; SET portal=# show temp_buffers; temp_buffers -------------- 2048 (1 row) > Deprecating setting the value directly in its base unit, so that all the > memory parameters are specified as a number of bytes, would sidestep a lot > of the issues people complain about. What I would like to see (but don't > have nearly enough time to argue in support of considering the resistance to > change here) is that this syntax: > > shared_buffers=1024 Silly me, perhaps, but in the absence of a unit, I would assume that a number in this context refers to a number of BUFFERS. I'd be willing to bet money that if you showed this line to a bunch of people who knew nothing about postgresql but were reasonably computer-savvy, you'd get a lot more people who thought that was a number of buffers than who thought it was a number of bytes. Compounding the problem, of course, is the fact, that right now, that's exactly what it does mean. While it's probably acceptable to change the semantics of postgresql.conf in such a way that this syntax is no longer accepted, or generates a warning, it's almost certainly a bad idea to change it to silently mean something that is four orders of magnitude different what it currently means. > Would assume the user meant 1024 *bytes*, with the server silently rounding > that up to the nearest 8k block. Then the whole issue of "do they mean bits > or bytes?" goes away, because no one would ever have to include the "B". I don't believe this issue exists in the first place, because anyone who would specify the size of their shared buffer pool in bits should have their head examined. But if, hypothetically, someone were confused, I can't imagine that taking away the "B" is somehow going to be more clear. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
