Re: Query Plan choice with timestamps
От
Giorgio Valoti
Тема
Re: Query Plan choice with timestamps
Дата
Msg-id
3CA742D3-1D67-4572-AD4A-F7AA479771C7@mac.com
Ответ на
Re: Query Plan choice with timestamps (Tom Lane)
Список
Дерево обсуждения
Query Plan choice with timestamps Giorgio Valoti <giorgio_v@mac.com>
Re: Query Plan choice with timestamps Tom Lane <tgl@sss.pgh.pa.us>
Re: Query Plan choice with timestamps Giorgio Valoti <giorgio_v@mac.com>
Re: Query Plan choice with timestamps Giorgio Valoti <giorgio_v@mac.com>
Re: Query Plan choice with timestamps Tom Lane <tgl@sss.pgh.pa.us>
Re: Query Plan choice with timestamps Giorgio Valoti <giorgio_v@mac.com>
Re: Query Plan choice with timestamps Richard Huxton <dev@archonet.com>
Re: Query Plan choice with timestamps Giorgio Valoti <giorgio_v@mac.com>
Re: Query Plan choice with timestamps Richard Huxton <dev@archonet.com>
Re: Query Plan choice with timestamps Giorgio Valoti <giorgio_v@mac.com>
On 07/ago/08, at 23:01, Tom Lane wrote: > Giorgio Valoti writes: >> On 07/ago/08, at 17:50, Tom Lane wrote: >>> These numbers seem pretty bogus: there is hardly any scenario in >>> which a >>> full-table indexscan should be costed as significantly cheaper >>> than a >>> seqscan. Have you put in silly values for random_page_cost? > >> No, > > I looked at it more closely and realized that the cost discrepancy is > from the evaluation of the function: having to evaluate a SQL or > plpgsql > function 247736 times more than explains the cost estimate > differential > compared to a query that involves no function call. Some experiments > here suggest that it hardly matters whether the query uses indexscan > or > seqscan because the time is dominated by the function calls anyway. I see, thank you Tom. Could it be a good idea adding some notes about it in ? As you said, since the function call dominates the query cost, in this case, I think there’s no point to use an index expression. Ciao -- Giorgio Valoti
В списке pgsql-performance по дате отправления