Re: Any better plan for this query?..

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Any better plan for this query?..
Дата
Msg-id 603c8f070905200417j7b000adueec51cd7b4ecc55d@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Any better plan for this query?..  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Any better plan for this query?..  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-performance
On Wed, May 20, 2009 at 4:11 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> The Hash node is fully executed before we start pulling rows through the
> Hash Join node. So the Hash Join node will know at execution time
> whether or not it will continue to maintain sorted order. So we put the
> Sort node into the plan, then the Sort node can just ask the Hash Join
> at execution time whether it should perform a sort or just pass rows
> through (act as a no-op).

It's not actually a full sort.  For example if the join has two
batches, you don't need to dump all of the tuples from both batches
into a sort.  Each of the two tapes produced by the hash join is
sorted, but if you read tape one and then tape two, of course then it
won't be.  What you want to do is read the first tuple from each tape
and return whichever one is smaller, and put the other one back; then
lather, rinse, and repeat.  Because it's such a special-case
computation, I think you're going to want to implement it within the
HashJoin node rather than inserting a Sort node (or any other kind).

...Robert

В списке pgsql-performance по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Any better plan for this query?..
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Any better plan for this query?..