effective_cache_size is a real?

Started by Peter Eisentrautover 19 years ago7 messageshackers
Jump to latest
#1Peter Eisentraut
peter_e@gmx.net

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/

#2Simon Riggs
simon@2ndQuadrant.com
In reply to: Peter Eisentraut (#1)
Re: effective_cache_size is a real?

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

#3Josh Berkus
josh@agliodbs.com
In reply to: Peter Eisentraut (#1)
Re: effective_cache_size is a real?

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

#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#1)
Re: effective_cache_size is a real?

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

#5Peter Eisentraut
peter_e@gmx.net
In reply to: Tom Lane (#4)
Re: effective_cache_size is a real?

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/

#6Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#5)
Re: effective_cache_size is a real?

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

#7Bruce Momjian
bruce@momjian.us
In reply to: Simon Riggs (#2)
Re: effective_cache_size is a real?

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.