Re: a JOIN on same table, but 'slided over'

Поиск
Список
Период
Сортировка
От Gurjeet Singh
Тема Re: a JOIN on same table, but 'slided over'
Дата
Msg-id 65937bea0706262211l2589da9apfb41211dd3d7c880@mail.gmail.com
обсуждение исходный текст
Ответ на Re: a JOIN on same table, but 'slided over'  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On 6/26/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"news.gmane.org" <nis@superlativ.dk> writes:
> Gurjeet Singh skrev:
>> Also note that this query is much cheaper that the 'distinct on' query
>> by more than two orders on magnitude ( 217.86 vs. 98040.67):

> No it isn't. The estimate is much lower, but the actual times are very
> close:

> [explain of distinct on]
>> Time: 5.003 ms

> [explain of correlated subquery]
>> Time: 4.125 ms

You're both confused:

???

the planner estimate certainly should not be taken
as gospel,

true

but the actual runtime of an EXPLAIN (not EXPLAIN ANALYZE)
only reflects planning effort.

Agree completely

EXPLAIN ANALYZE output would be a lot more suitable to settle the
question which one is faster.

Agree again. I was using the EXPLAIN output just to make a point that optimizer thinks the query utilizing a subquery is much cheaper (and hence maybe faster) than the 'distinct on' query.

In a later mail I posted the analyze o/p too...

--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com

17°29'34.37"N  78°30'59.76 "E - Hyderabad *
18°32'57.25"N  73°56'25.42"E - Pune

Sent from my BlackLaptop device

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

Предыдущее
От: Vivek Khera
Дата:
Сообщение: Re: growing disk usage problem: alternative solution?
Следующее
От: "Ashish Karalkar"
Дата:
Сообщение: Auto Vaccume- Time based