Re: Which file does the SELECT?

From: Vaibhav Kaushal <vaibhavkaushal123(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Which file does the SELECT?
Date: 2010-10-10 10:41:07
Message-ID: AANLkTinTEX6fGNmCuZxktB7Zs-WcpYiCqcaLwu4qhZKX@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

The PostgreSQL documentation (9.0.1) has the following section in section
44.5.1:

The planner preferentially considers joins between any two relations for
which
there exist a corresponding join clause in the WHERE qualification (i.e., for
which a restriction like
where rel1.attr1=rel2.attr2 exists). *Join pairs with no join clause are
considered only when*
there is no other choice, that is, a particular relation has no available
join clauses to any other relation.
All possible plans are generated for every join pair considered by the
planner, and the one that is
(estimated to be) the cheapest is chosen.

Can someone tell me what are 'Join Pairs with no Join clause' ? I am not
able to figure that out!

-Vaibhav (*_*)

On Sun, Oct 10, 2010 at 1:58 PM, Vaibhav Kaushal <
vaibhavkaushal123(at)gmail(dot)com> wrote:

> Thanks for the reply.
>
> So if I am not wrong, I will have to understand the whole querying process
> in detail? If it is so, then where do I start from?
>
> -Vaibhav
>
>
> On Sun, Oct 10, 2010 at 1:41 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>
>> On sön, 2010-10-10 at 13:32 +0530, Vaibhav Kaushal wrote:
>> > I have gone through the source code a bit but I wanted to know that
>> > which file contains the code that performs the final SLECTION after
>> > the optimizer has created the final plan? I mean which part of the
>> > executor is responsible for the SELCT to be run?
>>
>> That depends on what plan was chosen for the SELECT, since the executor
>> is primarily organized by plan node type, independent of which statement
>> caused the plan to be generated.
>>
>>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2010-10-10 11:48:17 Re: Review: Fix snapshot taking inconsistencies
Previous Message Neil Whelchel 2010-10-10 10:29:42 Re: Slow count(*) again...