Quoting Simon Riggs [EMAIL PROTECTED]:
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
Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] 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
Peter Eisentraut [EMAIL PROTECTED] 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
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
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
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
Peter Eisentraut [EMAIL PROTECTED] 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
