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

Re: Query planner unaware of possibly best plan

From: Denes Daniel <panther-d(at)freemail(dot)hu>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Query planner unaware of possibly best plan
Date: 2007-09-21 19:29:55
Message-ID: freemail.20070821212955.15119@fm03.freemail.hu (view raw or flat)
Thread:
Lists: pgsql-performance
Simon Riggs <simon(at)2ndquadrant(dot)com> írta:

> Ordering by parent, child is fairly common but the variation you've got
> here isn't that common. You'd need to make a case considering all the
> alternatives; nobody will agree without a balanced case that includes
> what is best for everyone.
> 
> Your EXPLAIN looks edited. Have you also edited the sort costs? They
> look slightly higher than we might expect. Please provide the full
> normal EXPLAIN output.
> 
> -- 
>   Simon Riggs
>   2ndQuadrant  http://www.2ndQuadrant.com



I've just inserted some newlines, so it's better to read than when my 
email-client wraps the lines automatically. Did not touch the information 
itself. But here is the normal output of EXPLAIN ANALYZE:

EXPLAIN ANALYZE SELECT * FROM tparent JOIN tchild ON tchild.par_id = 
tparent.id WHERE tparent.ord BETWEEN 1 AND 4 ORDER BY tparent.ord, 
tchild.ord;

                                                              QUERY PLAN
-------------------------------------------------------------------------------------------
--------------------------------------------
 Sort  (cost=100000132.10..100000140.10 rows=8 width=16) (actual 
time=0.302..0.319 rows=9 loops=1)
   Sort Key: tparent.ord, tchild.ord
   ->  Nested Loop  (cost=0.00..84.10 rows=8 width=16) (actual 
time=0.181..0.267 rows=9 loops=1)
         ->  Index Scan using par_uniq_ord on tparent  (cost=0.00..20.40 
rows=4 width=8) (actual time=0.100..0.109 rows=4 loops=1)
               Index Cond: ((ord >= 1) AND (ord <= 4))
         ->  Index Scan using chi_pkey_parid_ord on tchild  
(cost=0.00..9.93 rows=2 width=8) (actual time=0.020..0.026 rows=2 
loops=4)
               Index Cond: (tchild.par_id = "outer".id)
 Total runtime: 0.412 ms
(8 rows)

The costs may be different because I've tuned the query planner's 
parameters.

> Ordering by parent, child is fairly common but the variation you've got
> here isn't that common.
How else can you order by parent, child other than first ordering by a 
unique key of parent, then something in child? (Except for 
child.parent_id, child.something because this has all the information in 
child and can rely on a single multicolumn index.)


Denes Daniel
------------------------------------------------------------------------





Olvasd az [origo]-t a mobilodon: mini magazinok a Mobizin-en
___________________________________________________
www.t-mobile.hu/mobizin


In response to

Responses

pgsql-performance by date

Next:From: brauagustin-suscDate: 2007-09-21 19:33:46
Subject: Re: Low CPU Usage
Previous:From: Greg SmithDate: 2007-09-21 19:24:06
Subject: Re: Linux mis-reporting memory

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