Re: Huge Performance Difference on Similar Query in Pg7.2

Поиск
Список
Период
Сортировка
От Luis Alberto Amigo Navarro
Тема Re: Huge Performance Difference on Similar Query in Pg7.2
Дата
Msg-id 019101c1d19b$bc816fe0$cab990c1@atc.unican.es
обсуждение исходный текст
Ответ на Huge Performance Difference on Similar Query in Pg7.2  (Heiko Klein <Heiko.Klein@met.no>)
Ответы Re: Huge Performance Difference on Similar Query in Pg7.2  ("Nigel J. Andrews" <nandrews@investsystems.co.uk>)
Список pgsql-general
> Aggregate  (cost=5975.66..5975.66 rows=1 width=131) (actual
time=1264.12..1264.13 rows=1 loops=1)
>   ->  Hash Join  (cost=5958.18..5975.58 rows=35 width=131) (actual
time=1205.90..1262.46 rows=1606 loops=1)
>         ->  Hash Join  (cost=5956.30..5972.99 rows=35 width=127) (actual
time=1197.85..1248.93 rows=1606 loops=1)
 2)
> emep=> explain analyze select  count(*) from  EmissionsView ,
DataSetsView where  DataSetsView.setid = EmissionsView.setid and
DataSetsView.setid = '4614' ;
> NOTICE:  QUERY PLAN:
>
> Aggregate  (cost=91660.36..91660.36 rows=1 width=131) (actual
time=64414.80..64414.80 rows=1 loops=1)
>   ->  Hash Join  (cost=2732.23..91660.35 rows=3 width=131) (actual
time=58428.47..64413.14 rows=1606 loops=1)
>         ->  Nested Loop  (cost=2719.53..91058.61 rows=117798 width=103)
(actual time=49523.50..63005.67 rows=1025405 loops=1)

I think here is the difference, in the first case you are performing
hash-join from 33000 rows, in second case it is from 1M rows, so it is
wasting time on hashing, it seems that 1st conditions are more restrictive
than the second one. I mean there are less 4614 on EmissionsView than on
DataSetsView
Regards


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

Предыдущее
От: Heiko Klein
Дата:
Сообщение: Re: ODBC problem
Следующее
От: mark
Дата:
Сообщение: Re: ODBC problem