Re: optimising UNION performance
От | Alban Hertroys |
---|---|
Тема | Re: optimising UNION performance |
Дата | |
Msg-id | 44F2CDCD.5080504@magproductions.nl обсуждение исходный текст |
Ответ на | Re: optimising UNION performance (Rafal Pietrak <rafal@zorro.isa-geek.com>) |
Ответы |
Re: optimising UNION performance
|
Список | pgsql-general |
Rafal Pietrak wrote: > Thank you All for explanations. Looks loke that's what I was looking > for. > > UNION ALL is quite satisfactory (830ms). > > And yet, somwhere I loose c.a. 600ms (as compared to 120ms+80ms of each > respective 'raw' subquery).... which as percentage seem signifficant. > Does anybody know where the processing goes now? > > Currently, the ANALYSE looks like this: > QUERY > PLAN > ---------------------------------------------------------------------------------------------------------------------------------- > Subquery Scan comlog (cost=0.00..2269.71 rows=51400 width=0) (actual > time=0.053..755.649 rows=51400 loops=1) > -> Append (cost=0.00..1755.71 rows=51400 width=59) (actual > time=0.048..607.437 rows=51400 loops=1) > -> Subquery Scan "*SELECT* 1" (cost=0.00..1084.61 rows=30916 width=59) > (actual time=0.046..278.802 rows=30916 loops=1) > -> Seq Scan on log1 c (cost=0.00..775.45 rows=30916 width=59) (actual > time=0.042..170.193 rows=30916 loops=1) > -> Subquery Scan "*SELECT* 2" (cost=0.00..671.10 rows=20484 width=26) > (actual time=0.055..200.223 rows=20484 loops=1) > -> Seq Scan on log2 s (cost=0.00..466.26 rows=20484 width=26) (actual > time=0.044..127.301 rows=20484 loops=1) > Total runtime: 822.901 ms > (7 rows) > ----------------------------------------- Just to make sure: You do have an appropriate index over the tables in that UNION? From experience, it seems that PostgreSQL chooses a sequential scan over unioned sets instead of an index scan - the details escape me, but there is a good reason for that. I'm sure it's not for performance reasons, though. There have been some discussions about inheritance performance, which boils down to exactly this problem (inheritance basically is a UNION over all the tables involved). You may want to check the archives. Regards, -- Alban Hertroys alban@magproductions.nl magproductions b.v. T: ++31(0)534346874 F: ++31(0)534346876 M: I: www.magproductions.nl A: Postbus 416 7500 AK Enschede // Integrate Your World //
В списке pgsql-general по дате отправления: