In reply to Alvaro Herrera:
> The best thing to do is paste them in a text file and send it as an
> attachment.
Okay, it's attached.
> Why did you set enable_sort=off? It's not like sorting 9 rows is going
> to take any noticeable amount of time anyway.
Of course it's no problem for 9 rows, but this is only a test case. In
production there will be much more. I just wanted to show that the
planner doesn't even consider a plan without a sort step, using purely
index scans.
Denes Daniel
------------------------------------------------------------
Olvasd az [origo]-t a mobilodon: mini magazinok a Mobizin-en
___________________________________________________
www.t-mobile.hu/mobizin
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)
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
