Thank you for the advice, Tom.
My proposal is like this:
Suppose for the same query, Plan A consumes 10 units of I/O and 50
units of CPU. Plan B consumes 20 units of I/O and 40 units of CPU.
If A has less total cost than B, A will be selected as best plan.
If the database has less CPU available, I would prefer it to select
Plan B, which consumes less units of CPU.
I tried to limit the CPU to DB and modify cpu_tupe_cost, but no good.
I'm wondering if I need a particular query to do so.
The query I used is :
select
l_returnflag,
l_linestatus,
sum(l_quantity) as sum_qty,
sum(l_extendedprice) as sum_base_price,
sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
avg(l_quantity) as avg_qty,
avg(l_extendedprice) as avg_price,
avg(l_discount) as avg_disc,
count(*) as count_order
from
lineitem
where
l_shipdate <= date('1998-12-01') - interval '90 days'
group by
l_returnflag,
l_linestatus
order by
l_returnflag,
l_linestatus;
Hope this time I made it clear.
I apologize for any inconvenience caused by my post.
On Wed, Nov 30, 2011 at 11:23 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Yangyang <yangyangbm@gmail.com> writes:
>> If I don't change the database structures (like index), and only
>> modify "Planner cost constants", is it possible to make DB change the
>> query plan?
>
> Yes, but usually these don't have huge impacts on estimated costs,
> so you will only be able to get it to switch to plans that (it thinks)
> are relatively close in cost anyway.
>
> A bigger question is what sort of plan you think would be better, and
> whether the planner is even capable of building that plan from the
> given query. You didn't show the particular query you're concerned
> about, but I gather from the EXPLAIN output that it involves
> sub-selects, and those can act as optimization fences ...
>
> regards, tom lane