Re: Problem with collector statistic

Поиск
Список
Период
Сортировка
От Marco Aurélio V. da Silva
Тема Re: Problem with collector statistic
Дата
Msg-id 002801c8427a$aabc2740$0402a8c0@marquinho
обсуждение исходный текст
Ответ на Problem with collector statistic  (Marco Aurélio V. da Silva <marcoprodata@gmail.com>)
Ответы Re: Problem with collector statistic  ("Scott Marlowe" <scott.marlowe@gmail.com>)
Список pgsql-general
Sorry,

I discovered that the problem appears to be another, doing tests with the
same database, this is a consultation limit using the same database and with
9364 records of the problem, and with 9363 not of.
Next

bad query with bad results:
explain analyse Select a.CodPagador,b.Descricao
From Frete01 a Left Outer Join Frete02 b On (a.CodPagador = b.CodCliente)
limit 9364

"Limit  (cost=46619.72..46856.82 rows=9364 width=39) (actual
time=3442.510..3561.769 rows=9364 loops=1)"
"  ->  Merge Left Join  (cost=46619.72..48113.50 rows=58995 width=39)
(actual time=3442.505..3535.236 rows=9364 loops=1)"
"        Merge Cond: ("outer".codpagador = "inner".codcliente)"
"        ->  Sort  (cost=24649.80..24797.29 rows=58995 width=11) (actual
time=1347.896..1364.993 rows=9364 loops=1)"
"              Sort Key: a.codpagador"
"              ->  Seq Scan on frete01 a  (cost=0.00..19974.95 rows=58995
width=11) (actual time=9.001..558.582 rows=59161 loops=1)"
"        ->  Sort  (cost=21969.91..22274.37 rows=121784 width=39) (actual
time=2094.581..2115.666 rows=11976 loops=1)"
"              Sort Key: b.codcliente"
"              ->  Seq Scan on frete02 b  (cost=0.00..8127.84 rows=121784
width=39) (actual time=2.149..383.775 rows=121740 loops=1)"
"Total runtime: 3580.588 ms"



good query with good results:
explain analyse Select a.CodPagador,b.Descricao
From Frete01 a Left Outer Join Frete02 b On (a.CodPagador = b.CodCliente)
limit 9363

"Limit  (cost=0.00..46856.62 rows=9363 width=39) (actual
time=50.652..1864.420 rows=9363 loops=1)"
"  ->  Nested Loop Left Join  (cost=0.00..295237.26 rows=58995 width=39)
(actual time=50.647..1836.360 rows=9363 loops=1)"
"        ->  Seq Scan on frete01 a  (cost=0.00..19974.95 rows=58995
width=11) (actual time=8.948..215.558 rows=9363 loops=1)"
"        ->  Index Scan using frete02_f021 on frete02 b  (cost=0.00..4.65
rows=1 width=39) (actual time=0.163..0.166 rows=1 loops=9363)"
"              Index Cond: ("outer".codpagador = b.codcliente)"
"Total runtime: 1879.041 ms"


Thanks for your´s attention.


Marco Aurélio V. da Silva
Prodata Inf. e Cad. Ltda.
MSN: marco@prodatanet.com.br
Fone: (33) 3322-3082
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Marco Aurélio V. da Silva" <marcoprodata@gmail.com>
Cc: <pgsql-general@postgresql.org>
Sent: Wednesday, December 19, 2007 2:09 PM
Subject: Re: [GENERAL] Problem with collector statistic


> "=?iso-8859-1?Q?Marco_Aur=E9lio_V._da_Silva?=" <marcoprodata@gmail.com>
> writes:
>> Running a query on 2 database-equal, with the same indices, but with
>> slightly different data, I have a very different result of performance.
>> In
>> one the index is used to make the join, in another it is seqscan.
>
> The fact that one explain includes a Limit step, and the other does not,
> says that you are not really issuing the same query in both cases.
>
> regards, tom lane


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

Предыдущее
От: Howard Cole
Дата:
Сообщение: Re: Killing a session in windows
Следующее
От: "Scott Marlowe"
Дата:
Сообщение: Re: Problem with collector statistic