Estimating recursive query cost - Mailing list pgsql-hackers

From Josh Berkus
Subject Estimating recursive query cost
Date
Msg-id 483E2B79.9050209@agliodbs.com
Whole thread Raw
List 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 by date:

Previous
From: Josh Berkus
Date:
Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
Next
From: "Pavan Deolasee"
Date:
Subject: Re: Avoiding second heap scan in VACUUM