Re: slow UNIONing

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB SD
Тема Re: slow UNIONing
Дата
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA421273A@m0114.s-mxs.net
обсуждение исходный текст
Ответ на slow UNIONing  (Kovacs Zoltan <kovacsz@pc10.radnoti-szeged.sulinet.hu>)
Ответы Re: slow UNIONing
Список pgsql-hackers
> I experienced that UNIONs in 7.1.1 are rather slow:
> 
> tir=# explain (select nev from cikk) union (select 
> tevekenyseg from log);
> NOTICE:  QUERY PLAN:
> 
> Unique  (cost=667.63..687.18 rows=782 width=12)
>   ->  Sort  (cost=667.63..667.63 rows=7817 width=12)
>         ->  Append  (cost=0.00..162.17 rows=7817 width=12)
>               ->  Subquery Scan *SELECT* 1  (cost=0.00..28.16 
> rows=1316 width=12)
>                     ->  Seq Scan on cikk  (cost=0.00..28.16 
> rows=1316 width=12)
>               ->  Subquery Scan *SELECT* 2  
> (cost=0.00..134.01 rows=6501 width=12)
>                     ->  Seq Scan on log  (cost=0.00..134.01 
> rows=6501 width=12)
> 
> Of course a simple SELECT is fast:
> 
> tir=# explain select nev from cikk;
> NOTICE:  QUERY PLAN:
> 
> Seq Scan on cikk  (cost=0.00..28.16 rows=1316 width=12)
> 
> 
> For me it seems to be slow due to the sorting. Is this right?
> Is this normal at all? Is it possible to make it faster?

If you know, that your result does not produce duplicates
(which are filtered away with "union") you can use a 
"union all" which should be substantially faster, since it does 
not need to sort.

Andreas


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

Предыдущее
От: Martín Marqués
Дата:
Сообщение: Re: Putting timestamps in PostgreSQL log
Следующее
От: Michael Meskes
Дата:
Сообщение: Re: Large objects and ecpg