Re: slow UNIONing

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "Kovacs Zoltan" <kovacsz(at)pc10(dot)radnoti-szeged(dot)sulinet(dot)hu>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: slow UNIONing
Date: 2001-09-19 07:15:52
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA421273A@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2001-09-19 10:22:19 Re: slow UNIONing
Previous Message Michael Meskes 2001-09-19 06:41:43 Re: Large objects and ecpg