Re: [HACKERS] effective_cache_size is a real?
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 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. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] effective_cache_size is a real?
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 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] effective_cache_size is a real?
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 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/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] effective_cache_size is a real?
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq