Amit Kapila 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 as of HEAD. With th
ent: Wednesday, April 18, 2012 11:59 AM
To: Amit Kapila
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Improving our clauseless-join heuristics
Amit Kapila writes:
>> I'm afraid I'm still not following you very well. Perhaps you could
>> submit a proposed patch?
Amit Kapila 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 clause that bo
l-hackers@postgresql.org
Subject: Re: [HACKERS] Improving our clauseless-join heuristics
Amit Kapila 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
Amit Kapila 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 has any join cla
hich
can be possible may be not at this level but at next level.
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: Tuesday, April 17, 2012 2:05 AM
To: Amit Kapila
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Improving our clauseless-join heuristics
Amit Kapila writes:
Amit Kapila 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 of query, if the su
-2 it only consider later rels. So
it should not consider joining 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 he
Amit Kapila 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 example you have provi
2012 9:10 AM
To: Amit Kapila
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Improving our clauseless-join heuristics
Amit Kapila 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
Amit Kapila 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 join condition its
>
Sent: 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 *
On Fri, Apr 13, 2012 at 10:51 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Apr 13, 2012 at 10:32 AM, Tom Lane 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
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 regression
Robert Haas writes:
> On Fri, Apr 13, 2012 at 10:32 AM, Tom Lane 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 of these two
>> relations?". I
On Fri, Apr 13, 2012 at 10:32 AM, Tom Lane 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 = c.c or a.z =
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 th
17 matches
Mail list logo
