Re: Query slowing down significantly??

From: Yeb Havinga <yebhavinga(at)gmail(dot)com>
To: Rainer Pruy <Rainer(dot)Pruy(at)Acrys(dot)COM>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Query slowing down significantly??
Date: 2010-03-01 19:34:38
Message-ID: 4B8C16CE.6090901@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Rainer Pruy wrote:
> Thanks for the hint.
> I should have been considering that in the first place.
> (But the obvious is easily left unrecognised..)
>
> The prepared statement gives:
>
> QUERY PLAN
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
> Nested Loop (cost=0.00..25.18 rows=2 width=175) (actual time=36.116..49.998 rows=1 loops=1)
> -> Index Scan using x_context_01 on context c (cost=0.00..10.76 rows=2 width=67) (actual time=0.029..6.947 rows=12706 loops=1)
> Index Cond: ((contextid)::text = $1)
> -> Index Scan using x_fk_context_hierarchy_02 on context_hierarchy h (cost=0.00..7.20 rows=1 width=108) (actual time=0.003..0.003
> rows=0 loops=12706)
> Index Cond: (h.contextidx = c.idx)
> Filter: (((h.hierarchyname)::text = $2) AND (h.parentidx = $3))
> Total runtime: 50.064 ms
> (7 rows)
>
>
> And that is quite a bad plan given the current distribution of values.
>
Another approach might be to rewrite recursion into your hierarchy with
the in 8.4 new WITH RECURSIVE option in sql queries. The possible gains
there are way beyond anything you can accomplish with optimizing
recursive functions.

Regards,
Yeb Havinga

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Bruce Momjian 2010-03-02 03:33:53 Re: SSD + RAID
Previous Message Anj Adu 2010-03-01 19:29:26 partition pruning