Estimating recursive query cost

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Estimating recursive query cost
Дата
Msg-id 483E2B79.9050209@agliodbs.com
обсуждение исходный текст
Список pgsql-hackers
All,

I'm really uncomfortable with just having recursive queries return a 
cost of "1000" or some similar approach.  That's always been a problem 
for SRFs and it looks to be a bigger problem for WR.

However, it doesn't seem like the computer science establishment has 
made a lot of headway in this regard either.  Most approaches I found 
abstracts for would cost more CPU to calculate than the query was likely 
to take in order to execute.  Several of the stupider looking ones are 
for no apparent reason patented.

However, since we know for certain that the recursive query is going to 
be executed, and we don't have multiple choices of execution paths for 
it, it seems like our primary concern for estimation purposes is what 
portion of the table will be returned by the query, i.e. should we use a 
table scan or an index scan, if an appropriate index is available?

Or will that not be calculated at the recursive query level?

--Josh Berkus


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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: [PATCHES] WITH RECURSIVE patch V0.1
Следующее
От: "Pavan Deolasee"
Дата:
Сообщение: Re: Avoiding second heap scan in VACUUM