Merge joins sorta need their input to be sorted.
will trillich wrote:
>
> CREATE VIEW course AS
> SELECT
> e.code AS educode,
> e.name AS eduname,
> t.code AS topiccode,
> t.name AS topicname,
> c.id,
> c.topic,
> c.code,
> c.hrs,
> c.num,
> c.name,
> c.descr,
> c.created,
> c.modified,
> c.editor,
> c.status
> FROM
> _edu e,
> _topic t,
> _course c
> WHERE
> c.topic = t.id -- maybe this should be swapped
> AND
> t.edu = e.id -- with this ??
> ;
>
> psql=> explain select * from course;
> NOTICE: QUERY PLAN:
>
> Merge Join (cost=4.14..4.42 rows=8 width=238)
> -> Sort (cost=2.63..2.63 rows=5 width=60)
> -> Merge Join (cost=2.38..2.57 rows=5 width=60)
> -> Sort (cost=1.30..1.30 rows=11 width=32)
> -> Seq Scan on _topic (cost=0.00..1.11 rows=11 width=32)
> -> Sort (cost=1.08..1.08 rows=4 width=28)
> -> Seq Scan on _edu (cost=0.00..1.04 rows=4 width=28)
> -> Sort (cost=1.52..1.52 rows=17 width=178)
> -> Seq Scan on _course (cost=0.00..1.17 rows=17 width=178)
>
> EXPLAIN
>
> there's FOUR sort items mentioned there, and that's before the
> merge join (results will not be sorted in any particular order).
>
> which document will allay my 'holy cow is this ever gonna slow
> down my database performance' concerns? (perhaps by saying that
> sorting is just a myth, or by telling me how to get this puppy to
> not sort at all -- and to use the indexes that i've defined for
> all these joined fields...!)
>
> --
> It is always hazardous to ask "Why?" in science, but it is often
> interesting to do so just the same.
> -- Isaac Asimov, 'The Genetic Code'
>
> will@serensoft.com
> http://newbieDoc.sourceforge.net/ -- we need your brain!
> http://www.dontUthink.com/ -- your brain needs us!
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
--
Joseph Shraibman
jks@selectacast.net
Increase signal to noise ratio. http://www.targabot.com
