Re: Query planner unaware of possibly best plan - Mailing list pgsql-performance

From Denes Daniel
Subject Re: Query planner unaware of possibly best plan
Date
Msg-id freemail.20070821212955.15119@fm03.freemail.hu
Whole thread Raw
In response to Re: Query planner unaware of possibly best plan  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Query planner unaware of possibly best plan
List pgsql-performance
Simon Riggs <simon@2ndquadrant.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


pgsql-performance by date:

Previous
From: Greg Smith
Date:
Subject: Re: Linux mis-reporting memory
Next
From: brauagustin-susc@yahoo.com.ar
Date:
Subject: Re: Low CPU Usage