From: | Nicolas Barbier <nicolas(dot)barbier(at)gmail(dot)com> |
---|---|
To: | amit sehas <cun23(at)yahoo(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: query execution question |
Date: | 2011-02-09 23:30:50 |
Message-ID: | AANLkTim+4gPvFTeEEPb5au-EhXxzB_JxYArh6hFZTko1@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2011/2/9 amit sehas <cun23(at)yahoo(dot)com>:
> Lets say that the cost based optimizer determines that the order of the
> joins should be T1.a=T2.b followed by T2.c = T3.d followed by T3.e = T4.f
>
> the question we have is during query execution are the joins evaluated
> completely one by one in that order, or the first join is evaluated
> completely and generates an intermediate table which is then utilized
> to perform the next join....this means that for such a query we will need
> space for all the intermediate tables, which if they are very large tables
> as they are in our case can significantly alter the cost of the operations...
[ This is a question more appropriate for pgsql-performance. ]
The optimizer doesn't only determine the order (or "tree" actually) in
which to perform the joins, but also how to perform them: nested loop,
merge, or hash join. Depending on those physical join types, something
might need to be materialized (merge: the intermediate sort "tapes";
hash: the full outer operand's contents) or not (nested loop).
Please see the EXPLAIN statement if you want to know how the query
would be executed.
Nicolas
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2011-02-09 23:36:52 | Re: Transaction-scope advisory locks |
Previous Message | Chris Browne | 2011-02-09 23:07:14 | Re: Range Types - efficiency |