idth=4)
-> Seq Scan on b (cost=0.00..170.00 rows=9990 width=4)
Filter: (i > 10)
(7 rows)
In general, if the selectivity of the implied qual is low, the extra cost
for
relation scan is more likely to be compromised by the cost reduced in join,
and
vise versa.
Thanks
Richa
idth=4)
-> Seq Scan on b (cost=0.00..170.00 rows=9990 width=4)
Filter: (i > 10)
(7 rows)
In general, if the selectivity of the implied qual is low, the extra cost
for
relation scan is more likely to be compromised by the cost reduced in join,
and
vise versa.
Thanks
Richa
Hi,
On 2018-11-22 19:15:42 +0300, Alexander Kuzmenkov wrote:
> Hi Richard,
>
> I took a look at the v2, here are some comments:
>
> * This feature needs tests, especially for the cases where opfamilies or
> data types or collations don't match, and other non-obvious cases where it
> shouldn't wo
Hi Richard,
I took a look at the v2, here are some comments:
* This feature needs tests, especially for the cases where opfamilies or
data types or collations don't match, and other non-obvious cases where
it shouldn't work.
* Deducing an inequality to a constant is not always helpful. If w
Hi,
Thanks everyone for reviewing. We updated the patch and added more strict
checks for the non-equivalence clauses before deducing new quals, including:
1) The non-equivalence clause for deduction can only be type of OpExpr or
ScalarArrayOpExpr, with two arguments.
2) The operator of the non-e
On 05/09/18 09:34, Richard Guo wrote:
Hi,
As we know, current planner will generate additional restriction clauses
from
equivalence clauses. This will generally lower the total cost because
some of
tuples may be filtered out before joins.
In this patch, we are trying to do the similar deduct
Richard Guo writes:
> In this patch, we are trying to do the similar deduction, from
> non-equivalence
> clauses, that is, A=B AND f(A) implies A=B AND f(A) and f(B), under some
> restrictions on f.
Uh, *what* restrictions on f()? In general the above equivalence
does not hold, at least not for
On Wed, Sep 5, 2018 at 2:55 PM, Heikki Linnakangas wrote:
> On 05/09/18 09:34, Richard Guo wrote:
>
>> Hi,
>>
>> As we know, current planner will generate additional restriction clauses
>> from
>> equivalence clauses. This will generally lower the total cost because
>> some of
>> tuples may be fi
Hi,
On Wed, Sep 5, 2018 at 2:56 PM, Tom Lane wrote:
> Richard Guo writes:
> > In this patch, we are trying to do the similar deduction, from
> > non-equivalence
> > clauses, that is, A=B AND f(A) implies A=B AND f(A) and f(B), under some
> > restrictions on f.
>
> Uh, *what* restrictions on f()
Hi,
On 2018-11-22 19:15:42 +0300, Alexander Kuzmenkov wrote:
> Hi Richard,
>
> I took a look at the v2, here are some comments:
>
> * This feature needs tests, especially for the cases where opfamilies or
> data types or collations don't match, and other non-obvious cases where it
> shouldn't wo
Hi Richard,
I took a look at the v2, here are some comments:
* This feature needs tests, especially for the cases where opfamilies or
data types or collations don't match, and other non-obvious cases where
it shouldn't work.
* Deducing an inequality to a constant is not always helpful. If w
On 05/09/18 09:34, Richard Guo wrote:
Hi,
As we know, current planner will generate additional restriction clauses
from
equivalence clauses. This will generally lower the total cost because
some of
tuples may be filtered out before joins.
In this patch, we are trying to do the similar deduct
Richard Guo writes:
> In this patch, we are trying to do the similar deduction, from
> non-equivalence
> clauses, that is, A=B AND f(A) implies A=B AND f(A) and f(B), under some
> restrictions on f.
Uh, *what* restrictions on f()? In general the above equivalence
does not hold, at least not for
On Wed, Sep 5, 2018 at 2:55 PM, Heikki Linnakangas wrote:
> On 05/09/18 09:34, Richard Guo wrote:
>
>> Hi,
>>
>> As we know, current planner will generate additional restriction clauses
>> from
>> equivalence clauses. This will generally lower the total cost because
>> some of
>> tuples may be fi
Hi,
On Wed, Sep 5, 2018 at 2:56 PM, Tom Lane wrote:
> Richard Guo writes:
> > In this patch, we are trying to do the similar deduction, from
> > non-equivalence
> > clauses, that is, A=B AND f(A) implies A=B AND f(A) and f(B), under some
> > restrictions on f.
>
> Uh, *what* restrictions on f()
Hi,
Thanks everyone for reviewing. We updated the patch and added more strict
checks for the non-equivalence clauses before deducing new quals, including:
1) The non-equivalence clause for deduction can only be type of OpExpr or
ScalarArrayOpExpr, with two arguments.
2) The operator of the non-e
16 matches
Mail list logo
