* 高健 (luckyjack...@gmail.com) wrote:
[...]
> postgres=# explain analyze select * from sales s inner join customers c on
> s.cust_id = c.cust_id and c.cust_id =2;
[...]
> When I use the where condition such as ,
>
> postgresql is clever enough to know it is better to make seqscan and
> filter ?
Hello:
Thanks for replying!
I understand it a little more.
And I compared the following statements:
First:
postgres=# explain analyze select * from sales s inner join customers c on
s.cust_id = c.cust_id;
QUERY
PLAN
-
Stephen Frost writes:
> * é«å¥ (luckyjack...@gmail.com) wrote:
>> Why the reduction is needed here for cost calculation?
> cost_qual_eval(&hash_qual_cost, hashclauses, root);
> returns the costs for *just the quals which can be used for the
> hashjoin*, while
> cost_qual_eval(&qp_
Greetings,
* 高健 (luckyjack...@gmail.com) wrote:
> And I found the following function of PostgreSQL9.2.1. The hash join cost
> is calculated.
>
> But what confused me is a reuction calculation:
>
> qp_qual_cost.per_tuple -= hash_qual_cost.per_tuple;
>
> My question is:
>
> Why the reduction i
Hi :
Sorry for disturbing. I don't know if it is ok to put this question here.
I want to learn more about hash join's cost calculation.
And I found the following function of PostgreSQL9.2.1. The hash join cost
is calculated.
But what confused me is a reuction calculation:
qp_qual_cos
