From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | david(at)fetter(dot)org |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WITH RECURSIVE patches V0.1 TODO items |
Date: | 2008-05-27 04:31:52 |
Message-ID: | 20080527.133152.90119862.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > > 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jignesh K. Shah | 2008-05-27 05:01:51 | Re: [GSoC08]some detail plan of improving hash index |
Previous Message | Andrew Dunstan | 2008-05-27 04:23:51 | Re: WITH RECURSIVE patches V0.1 TODO items |