Thread: 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.