Re: 7.4 vs 7.3 ( hash join issue )

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: 7.4 vs 7.3 ( hash join issue )
Дата
Msg-id 87brfycfbf.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: 7.4 vs 7.3 ( hash join issue )  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: 7.4 vs 7.3 ( hash join issue )  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Yeah, I was just looking at doing that.

Well I imagine it takes you as long to read my patch as it would for you to
write it. But anyways it's still useful to me as exercises.

> It would also be interesting to prefetch one row from the outer table and fall
> out immediately (without building the hash table) if the outer table is
> empty.  This seems to require some contortion of the code though :-(

Why is it any more complicated than just moving the hash build down lower?
There's one small special case needed in ExecHashJoinOuterGetTuple but it's
pretty non-intrusive.

It seems to work for me but I can't test multiple batches easily. I think I've
convinced myself that they would work fine but...

test=# explain analyze select * from a natural join b;
                                             QUERY PLAN
-----------------------------------------------------------------------------------------------------
 Hash Join  (cost=22.50..345.00 rows=5000 width=4) (actual time=0.005..0.005 rows=0 loops=1)
   Hash Cond: ("outer".a = "inner".a)
   ->  Seq Scan on a  (cost=0.00..20.00 rows=1000 width=4) (actual time=0.002..0.002 rows=0 loops=1)
   ->  Hash  (cost=20.00..20.00 rows=1000 width=4) (never executed)
         ->  Seq Scan on b  (cost=0.00..20.00 rows=1000 width=4) (never executed)
 Total runtime: 0.070 ms
(6 rows)



--
greg

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: 7.4 vs 7.3 ( hash join issue )
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 7.4 vs 7.3 ( hash join issue )