> > > Right for this case. Is there some way to estimate this short of
> > > a full-on materialized views implementation? I'm guessing we'd
> > > need to be able to cache the transitive closure of such searches.
> >
> > I did some discussion with Gregory Stark and Michael Makes at PGCon.
> > We tend to agree that very low constant cost for Recursive Scan
> > (probably plain 0 is not good though) is not so bad, since this
> > would emit plan which hashes the result of Recusive scan in a hash
> > join plan which is probably not so bad for most cases.
>
> It's good to know someone with the knowledge has some better estimate :)
Tom has no idea either. So it seems there's no one in the community
who could do the better estimation.
> > Also I talked with him that it would be nice we could have a kind of
> > distributed source repository to co-develop patches.
>
> This is just the kind of thing git
> <http://wiki.postgresql.org/wiki/Working_with_Git> was designed for.
>
> Who has tried it in your organization?
No one. From what I understannd from the URL above, it still needs to
exchange each member's work as diff files, which is why I want to make
up new CVS repostory. Correct me if I'm wrong.
--
Tatsuo Ishii
SRA OSS, Inc. Japan