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
****tion 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
