Re: Join Query Perfomance Issue
От | Tom Lane |
---|---|
Тема | Re: Join Query Perfomance Issue |
Дата | |
Msg-id | 15212.1202917722@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Join Query Perfomance Issue (Thomas Zaksek <zaksek@ptt.uni-due.de>) |
Ответы |
Re: Join Query Perfomance Issue
|
Список | pgsql-performance |
Thomas Zaksek <zaksek@ptt.uni-due.de> writes: > Nested Loop Left Join (cost=0.00..32604.48 rows=3204 width=14) (actual > time=11.991..2223.227 rows=2950 loops=1) > -> Index Scan using > messungen_v_dat_2007_11_12_messpunkt_minute_tag_idx on > messungen_v_dat_2007_11_12 m (cost=0.00..5371.09 rows=3204 width=4) > (actual time=0.152..12.385 rows=2950 loops=1) > Index Cond: ((ganglinientyp = 'M'::bpchar) AND (992 = minute_tag)) > -> Index Scan using messwerte_mv_nr_idx on messwerte_mv w > (cost=0.00..8.49 rows=1 width=18) (actual time=0.730..0.734 rows=1 > loops=2950) > Index Cond: (w.nr = m.messpunkt) > Total runtime: 2234.143 ms > (6 rows) > To me this plan looks very clean and nearly optimal, For so many rows I'm surprised it's not using a bitmap indexscan. What PG version is this? How big are these tables? regards, tom lane
В списке pgsql-performance по дате отправления: