Skip site navigation (1) Skip section navigation (2)

Re: Recursive Queries

From: Hubert FONGARNAND <informatique(dot)internet(at)fiducial(dot)fr>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Recursive Queries
Date: 2007-01-26 11:12:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
The CONNECT BY patch from evgen potemkin has been ported to  pg 8.2...
and it's now in BSD License...

I will test it on our test environement

Le jeudi 25 janvier 2007 à 11:08 +0000, Gregory Stark a écrit :

> Hm, having skimmed through the Evgen Potemkin's recursive queries patch I find
> it quite different from what I was expecting. My own thinking was headed off
> in a different direction.
> Basically the existing patch reimplements a new kind of join which implements
> a kind of nested loop join (with newer versions adding a kind of hash join)
> which feeds a new kind of tuplestore called a tupleconn.
> I was thinking to have a new node above a standard join. The new node would
> repeatedly feed back down to the join the results of the previous iteration
> and reexecute the join to get the next generation.
> I think my approach is more in line with the DB2/ANSI "WITH" style query which
> is expected to do a breadth-first search. The Oracle CONNECT BY syntax is
> expected to do a depth first search.
> I have two major issues with the repeated-join model though. 
> a) Ideally we would want to switch between nested loop, merge join, and hash
> join depending on the size of the previous generation. That means the join
> node wouldn't be the same type of join for all the iterations. This is
> important since in most applications you're traversing either up or down a
> tree and are likely starting with very few nodes but often ending up with very
> broad levels with many nodes. No single type of join will be appropriate for
> the whole plan execution.
> b) I do want to be able to support depth-first searching too. I'm not sure how
> to reconcile that with the repeated-join conceptual model. We could always
> resort the entire result set after generating it but that seems like an
> unsatisfactory solution.
Ce message et les ventuels documents joints peuvent contenir des informations confidentielles.
Au cas o il ne vous serait pas destin, nous vous remercions de bien vouloir le supprimer et en aviser immdiatement l'expditeur. Toute utilisation de ce message non conforme  sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.
Les communications sur internet n'tant pas scurises, l'intgrit de ce message n'est pas assure et la socit mettrice ne peut tre tenue pour responsable de son contenu.

In response to

pgsql-hackers by date

Next:From: Markus SchiltknechtDate: 2007-01-26 11:13:39
Subject: Re: Proposal: Change of pg_trigger.tg_enabled and adding
Previous:From: Heikki LinnakangasDate: 2007-01-26 10:54:25
Subject: Re: Proposal: Commit timestamp

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group