Thread: DAGs and recursive queries

DAGs and recursive queries

From
"paul.dorman"
Date:
Hi everyone,

I would like to know the best way to implement a DAG in PostgreSQL. I
understand there has been some talk of recursive queries, and I'm
wondering if there has been much progress on this.

Are there any complete examples of DAGs which work with PostgreSQL? I
would like to be able to do the following operations for a
categorization system:

1. Given a node, get one or more field values out of every parent node
2. Given a parent node, get one or more field values out of every
child node
3. Given two or more parent nodes, identify any common children.

I do not need to determine shortest paths between parents and
children, only to be able to iterate over them as efficiently as
possible.

I'd like to keep things dynamic so changes up the hierarchy don't
require changes to any of the children (unless their direct parents
are changed). I'd also like to keep as much processing as possible in
the database to minimize the traffic between my application and the
DB, so I think I'm looking for SQL and stored procedure solutions.

Any pointers would be great, as I'm not a DBA and do not have the
experience to make judgments about the best possible approach.

Regards,
Paul Dorman


Re: DAGs and recursive queries

From
Gregory Stark
Date:
"paul.dorman" <paul.dorman@gmail.com> writes:

> Hi everyone,
>
> I would like to know the best way to implement a DAG in PostgreSQL. I
> understand there has been some talk of recursive queries, and I'm
> wondering if there has been much progress on this.

The ANSI recursive queries didn't make it into 8.3. I still hope it makes 8.4.

You could check out the tablefunc contrib which includes a function called
connectby() which implements a kind of recursive query.

Alternatively you might look at the ltree contrib module but that doesn't work
the way you describe. It denormalizes the data for very fast but less flexible
operations.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

Re: DAGs and recursive queries

From
Oleg Bartunov
Date:
take a look on contrib/ltree

On Wed, 26 Sep 2007, paul.dorman wrote:

> Hi everyone,
>
> I would like to know the best way to implement a DAG in PostgreSQL. I
> understand there has been some talk of recursive queries, and I'm
> wondering if there has been much progress on this.
>
> Are there any complete examples of DAGs which work with PostgreSQL? I
> would like to be able to do the following operations for a
> categorization system:
>
> 1. Given a node, get one or more field values out of every parent node
> 2. Given a parent node, get one or more field values out of every
> child node
> 3. Given two or more parent nodes, identify any common children.
>
> I do not need to determine shortest paths between parents and
> children, only to be able to iterate over them as efficiently as
> possible.
>
> I'd like to keep things dynamic so changes up the hierarchy don't
> require changes to any of the children (unless their direct parents
> are changed). I'd also like to keep as much processing as possible in
> the database to minimize the traffic between my application and the
> DB, so I think I'm looking for SQL and stored procedure solutions.
>
> Any pointers would be great, as I'm not a DBA and do not have the
> experience to make judgments about the best possible approach.
>
> Regards,
> Paul Dorman
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>               http://www.postgresql.org/docs/faq
>

     Regards,
         Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

Re: DAGs and recursive queries

From
Jeff Davis
Date:
On Wed, 2007-09-26 at 16:54 +0100, Gregory Stark wrote:
> "paul.dorman" <paul.dorman@gmail.com> writes:
>
> > Hi everyone,
> >
> > I would like to know the best way to implement a DAG in PostgreSQL. I
> > understand there has been some talk of recursive queries, and I'm
> > wondering if there has been much progress on this.
>
> The ANSI recursive queries didn't make it into 8.3. I still hope it makes 8.4.
>
> You could check out the tablefunc contrib which includes a function called
> connectby() which implements a kind of recursive query.
>
> Alternatively you might look at the ltree contrib module but that doesn't work
> the way you describe. It denormalizes the data for very fast but less flexible

Ltree seems like it might be a good option for him. What doesn't it do
that he needs?

I am also interested in graphs and trees in relational databases. Can
you recommend any good books? I particularly like CJ Date as an author,
but I can't find anything by him that specifically addresses this topic.

Also, how exactly is the database denormalized by using ltree?

Regards,
    Jeff Davis


Re: DAGs and recursive queries

From
Gregory Stark
Date:
"Jeff Davis" <pgsql@j-davis.com> writes:

> On Wed, 2007-09-26 at 16:54 +0100, Gregory Stark wrote:
>
>> You could check out the tablefunc contrib which includes a function called
>> connectby() which implements a kind of recursive query.
>>
>> Alternatively you might look at the ltree contrib module but that doesn't work
>> the way you describe. It denormalizes the data for very fast but less flexible
>
> Ltree seems like it might be a good option for him. What doesn't it do
> that he needs?
...
> Also, how exactly is the database denormalized by using ltree?

It keeps the same information in more than one place. Consider:

1
1.1
1.1.1

Note that all three records contain the root's id of "1". If you want to
reparent 1.1 to be 2.1 you have to know that all its children also need to be
reparented as well.

That's what he said he wanted to be able to do. In general if you have a
relatively static hierarchy something like ltree works very well but if you
have a very dynamic hierarchy where nodes move around freely it's not a very
good fit.


--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

Re: DAGs and recursive queries

From
Jeff Davis
Date:
On Thu, 2007-09-27 at 23:58 +0100, Gregory Stark wrote:
> It keeps the same information in more than one place. Consider:
>
> 1
> 1.1
> 1.1.1
>
> Note that all three records contain the root's id of "1". If you want to
> reparent 1.1 to be 2.1 you have to know that all its children also need to be
> reparented as well.

Aren't there still some update anomolies with any schema representing a
DAG?

Regards,
    Jeff Davis


Re: DAGs and recursive queries

From
"paul.dorman"
Date:
Thanks for your answers guys. I've got a cold right now and my brain
is mush, so I can't comment intelligently on your suggestions just
yet. I just wanted to express my thanks for your time.

Jeff, one book you might want to look at is Joe Celko's Trees and
Hierarchies in SQL for Smarties.

http://www.amazon.com/Hierarchies-Smarties-Kaufmann-Management-Systems/dp/1558609202

If the connectby() function is like the Oracle connectby function,
then perhaps it will suit my needs. The categorization scheme will
nearly always have multiple parents for all but the topmost node. Each
category stores serialized method calls for CRUD operations on objects
within the category, which are requested by the application for all
interactions with stored objects (though I'd like to be able to cache
them too, but that's in the application domain). Each object stored in
the database will belong to at least one category, but I expect they
will normally belong to many categories. When I create a new object of
categoryD, which is a child of categoryC and categoryB, which are
children of categoryA, then my application will need the CREATE method
calls from all parents, as well as the object category itself. I'd
like them all returned from one query, possibly ordered according to
the distance from the child node.

Oops, I'm trying to comment intelligently. Better stop now.

Cheers,
Paul