From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Martin Marques <martin(at)bugs(dot)unl(dot)edu(dot)ar> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Bitmap Heap scan 8.1/8.2 |
Date: | 2007-10-23 12:54:57 |
Message-ID: | 20071023125456.GC5772@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Martin Marques escribió:
> Martin Marques escribió:
>> Pavel Stehule wrote:
>>>
>>> try
>>>
>>> set work_mem to '8MB';
>>> and
>>> explain analyze select ..
>> These things didn't help. What changed the plan completely was this:
>> seq_page_cost = 5.0 # measured on an arbitrary scale
>> cpu_tuple_cost = 0.05 # same scale as above
>
> Can someone explain how this parameters are measured? What is 5.0 in this
> case for seq_page_cost?
It's an arbitrary number, based on which all the other numbers are
measured.
What people generally do around here is mess with random_page_cost, and
leave seq_page_cost alone. Often, it's the ratio
seq_page_cost/random_page_cost what's most important to the cost
equations results. (seq_page_cost wasn't tunable at all until
recently, say 8.1 or 8.2 AFAIR).
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-10-23 13:43:56 | Re: Determine query run-time from pg_* tables |
Previous Message | Benjamin Weaver | 2007-10-23 12:42:18 | Re: unicode searches failing that use % and LIKE operators |