Estimating recursive query cost

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Estimating recursive query cost
Date: 2008-05-29 04:05:13
Message-ID: 483E2B79.9050209@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2008-05-29 04:27:51 Re: Avoiding second heap scan in VACUUM
Previous Message Josh Berkus 2008-05-29 03:34:14 Re: [HACKERS] WITH RECURSIVE patch V0.1