Re: Lot'sa joins - performance tip-up, please?

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: Lot'sa joins - performance tip-up, please?
Дата
Msg-id 20060510221048.GX99570@pervasive.com
обсуждение исходный текст
Ответ на Re: Lot'sa joins - performance tip-up, please?  (Mario Splivalo <msplival@jagor.srce.hr>)
Ответы Re: Lot'sa joins - performance tip-up, please?  (Mario Splivalo <msplival@jagor.srce.hr>)
Список pgsql-performance
On Thu, May 04, 2006 at 04:45:57PM +0200, Mario Splivalo wrote:
Well, here's the problem...

>          ->  Nested Loop  (cost=0.00..176144.30 rows=57925 width=26)
> (actual time=1074.984..992536.243 rows=57925 loops=1)
>                ->  Seq Scan on ticketing_codes_played
> (cost=0.00..863.25 rows=57925 width=8) (actual time=74.479..2047.993
> rows=57925 loops=1)
>                ->  Index Scan using ticketing_codes_pk on
> ticketing_codes  (cost=0.00..3.01 rows=1 width=18) (actual
> time=17.044..17.052 rows=1 loops=57925)
>                      Index Cond: (ticketing_codes.code_id =
> "outer".code_id)

Anyone have any idea why on earth it's doing that instead of a hash or
merge join?

In any case, try swapping the order of ticketing_codes_played and
ticketing_codes. Actually, that'd probably make it worse.

Try SET enable_nestloop = off;
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

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

Предыдущее
От: Thomas Vatter
Дата:
Сообщение: Re: in memory views
Следующее
От: Kris Jurka
Дата:
Сообщение: Re: in memory views