Amit Kapila amit.kap...@huawei.com writes:
I'm afraid I'm still not following you very well. Perhaps you could
submit a proposed patch?
Before that can you please explain in little more detail (if possible with
small example) about the idea you have told in original mail : is there any
join
Kapila
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Improving our clauseless-join heuristics
Amit Kapila amit.kap...@huawei.com writes:
I'm afraid I'm still not following you very well. Perhaps you could
submit a proposed patch?
Before that can you please explain in little more detail
Amit Kapila amit.kap...@huawei.com writes:
The way I am telling was as below code.
With this extra paths will get generated, but it will as well consider for
joining c and d in query:
select * from a, b, c, d where a.x = b.y and (a.z = c.c or a.z = d.d)
I think this would just be dead code
Amit Kapila amit.kap...@huawei.com writes:
I might still be misunderstanding, but I think what you are suggesting
is that in the loop in make_rels_by_clause_joins, if we find that the
old_rel doesn't have a join clause/restriction with the current
other_rel, we check to see whether other_rel
: [HACKERS] Improving our clauseless-join heuristics
Amit Kapila amit.kap...@huawei.com writes:
I might still be misunderstanding, but I think what you are suggesting
is that in the loop in make_rels_by_clause_joins, if we find that the
old_rel doesn't have a join clause/restriction
with each other rel.
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Monday, April 16, 2012 9:57 AM
To: Amit Kapila
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Improving our clauseless-join heuristics
Amit Kapila amit.kap...@huawei.com writes:
That case
Amit Kapila amit.kap...@huawei.com writes:
For this kind of query, currently (referring 9.0.3 code) also it considers
join of b,c and b,d.
As there is no join clause between b,c,d so it will go in path of
make_rels_by_clauseless_joins() where it considers join of b,c and b,d.
In this kind
17, 2012 2:05 AM
To: Amit Kapila
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Improving our clauseless-join heuristics
Amit Kapila amit.kap...@huawei.com writes:
For this kind of query, currently (referring 9.0.3 code) also it considers
join of b,c and b,d.
As there is no join
: Friday, April 13, 2012 8:02 PM
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] Improving our clauseless-join heuristics
I looked into the behavior complained of here:
http://archives.postgresql.org/pgsql-performance/2012-04/msg00093.php
The problem query can be abstracted to
select * from
Amit Kapila amit.kap...@huawei.com writes:
I want to clarify small doubt in this regard.
In function make_rels_by_clause_joins(..), it tries to join the given
relation old_rel with other relations if there exist a join between them.
What I can understand is, it is because if there exists a
Kapila
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Improving our clauseless-join heuristics
Amit Kapila amit.kap...@huawei.com writes:
I want to clarify small doubt in this regard.
In function make_rels_by_clause_joins(..), it tries to join the given
relation old_rel with other
Amit Kapila amit.kap...@huawei.com writes:
That case is handled by make_rels_by_clauseless_joins
It will be handled by make_rels_by_clauseless_joins() if given rel old_rel
doesn't have any join clause.
However if it has join clause but doesn't able to join with any other rels
like in the
I looked into the behavior complained of here:
http://archives.postgresql.org/pgsql-performance/2012-04/msg00093.php
The problem query can be abstracted to
select * from a, b, c, d
where a.x = b.y and (a.z = c.c or a.z = d.d)
Table a is much larger than the others (in fact, in
On Fri, Apr 13, 2012 at 10:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I looked into the behavior complained of here:
http://archives.postgresql.org/pgsql-performance/2012-04/msg00093.php
The problem query can be abstracted to
select * from a, b, c, d
where a.x = b.y and (a.z =
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 13, 2012 at 10:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
After some reflection I think that the blame should be pinned on
have_relevant_joinclause(), which is essentially defined as is there
any join clause that can be evaluated at the join
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
I'm a bit worried, though, that with all the planner changes this
release we are going to spend a lot of time tracking down regressions
either in planning time or in plan quality.
I dunno, I agree that there will likely be more regressions,
On Fri, Apr 13, 2012 at 10:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Apr 13, 2012 at 10:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
After some reflection I think that the blame should be pinned on
have_relevant_joinclause(), which is essentially
17 matches
Mail list logo
