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

Re: improvements to query with hierarchical elements

From: Steve Midgley <public(at)misuse(dot)org>
To: Ryan Wallace <rywall(at)interchange(dot)ubc(dot)ca>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: improvements to query with hierarchical elements
Date: 2008-01-25 08:38:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-sql
At 07:24 PM 1/22/2008, you wrote:
>Hi all,
>I have created a little test database to help illustrate my situation.
>CREATE TABLE categories (
>     id integer NOT NULL,
>     name character varying(255) NOT NULL,
>     description character varying(255),
>     vocabulary_id integer,
>     derived boolean
>CREATE TABLE category_descendants (
>     id integer NOT NULL,
>     ancestor_id integer,
>     descendant_id integer,
>     distance integer,
>     derived boolean
>CREATE TABLE category_links (
>     id integer NOT NULL,
>     parent_id integer,
>     child_id integer,
>     derived boolean
>As stated in my last post, any help you can give on how to improve 
>queries of this type would be very much appreciated.

Hi Ryan,

I've been toying with your sample data for a bit and I apologize but 
your query has me baffled. Not that it's wrong - it actually looks very 
sophisticated, but it seems super complex to me - kind of like how I 
usually feel reading perl.. :)

I'm sure real sql-heads would get it right away but I'm not able to.

If you're looking to optimize the use-case you provided in your first 
email, the best thing I can suggest from what I understand would make 
an assumption:

Are the data in your tables are slowly changing? So could you build 
some analytic/pre-calculated data into these tables or related 
supporting ones to guide your searches/queries?

For example, if you want to find only records which are immediate 
children of other records, why not make a table which stores just that 
information? Your current tables are fully hierarchical which is great, 
but you want to look things up quickly based on a specific 
relationship: records who are direct children of a particular record..

So if you made a calculated table that stores this information, you 
could keep it up to date either by running the calculation script 
periodically or by attaching updates to relevant triggers / rules.

I'm sorry I'm not able to get into the SQL / example you sent further. 
I got lost in the code, which I'm a little embarrassed to admit but 
there you are.

If you're interested in this idea of precalculating values to optimize 
your search, I'd be happy to discuss further. Also, Ralph Kimball's 
Data Warehousing books are excellent on this subject (one of the few 
authors who truly changed the way I think about data).


pgsql-sql by date

Next:From: Frank BaxDate: 2008-01-25 14:15:31
Subject: Re: date format
Previous:From: Phillip SmithDate: 2008-01-25 04:11:30
Subject: Re: Extract interdependent info from one table

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