effective_cache_size is a real?
Is it intentional that effective_cache_size is a real (as opposed to
integer)? The initial revision of guc.c already has it that way, so it
was probably blindly adapted from the previous adhockery that had all
planner variables be doubles.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
On Mon, 2006-07-24 at 22:55 +0200, Peter Eisentraut wrote:
Is it intentional that effective_cache_size is a real (as opposed to
integer)? The initial revision of guc.c already has it that way, so it
was probably blindly adapted from the previous adhockery that had all
planner variables be doubles.
Makes no sense to me as a real. It should be an integer, since it is the
effective number of cache pages, not KB, MB or GB.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Peter,
Is it intentional that effective_cache_size is a real (as opposed to
integer)? The initial revision of guc.c already has it that way, so it
was probably blindly adapted from the previous adhockery that had all
planner variables be doubles.
I beleive that it's a real because the other query estimate variables
are reals. Might be worth checking the estimation code to make sure
that changing the type won't break anything.
--Josh
Peter Eisentraut <peter_e@gmx.net> writes:
Is it intentional that effective_cache_size is a real (as opposed to
integer)?
Yes --- the planner generally does all that stuff in float arithmetic to
avoid worrying about overflow.
regards, tom lane
Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
Is it intentional that effective_cache_size is a real (as opposed
to integer)?Yes --- the planner generally does all that stuff in float arithmetic
to avoid worrying about overflow.
Point taken, but I'm inclined to convert it to an integer anyway,
because that will make the units support much easier. The variable is
only used in exactly one place anyway, so making sure the calculation
works right should be easy.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
Point taken, but I'm inclined to convert it to an integer anyway,
because that will make the units support much easier. The variable is
only used in exactly one place anyway, so making sure the calculation
works right should be easy.
Casting it to double shouldn't take many cycles, so go ahead. I assume
you're planning to make the units support handle integer variables only?
I can't see any other float GUC vars where units support would be real
useful ...
regards, tom lane
Quoting Simon Riggs <simon@2ndquadrant.com>:
On Mon, 2006-07-24 at 22:55 +0200, Peter Eisentraut wrote:
Is it intentional that effective_cache_size is a real (as opposed to
integer)? The initial revision of guc.c already has it that way, so it
was probably blindly adapted from the previous adhockery that had all
planner variables be doubles.Makes no sense to me as a real. It should be an integer, since it is the
effective number of cache pages, not KB, MB or GB.
But cache pages are just a unit of memory themselves. From a user point
of view
we should get away from having the DBA have to know how large the page size is
altogether except when actually tweaking it.