From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | luvar(at)plaintext(dot)sk |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Some question |
Date: | 2010-04-06 18:45:59 |
Message-ID: | p2kdcc563d11004061145g928107c0gc73c2b860eee677@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2010/3/31 Ľubomír Varga <luvar(at)plaintext(dot)sk>:
> Hi, stright to my "problem":
> If I try to select constant 1 from table with two rows, it will be something
> like this:
>
> explain
> SELECT * FROM t_route
> WHERE t_route.route_type_fk = (SELECT id FROM t_route_type WHERE type = 2)
> limit 4;
>
> "Limit (cost=1.02..1.91 rows=4 width=2640)"
> " InitPlan"
> " -> Seq Scan on t_route_type (cost=0.00..1.02 rows=1 width=8)"
> " Filter: ("type" = 2)"
> " -> Seq Scan on t_route (cost=0.00..118115.25 rows=535090 width=2640)"
> " Filter: (route_type_fk = $0)"
>
Looking at this it looks like you're using prepared queries, which
can't make as good of a decision as regular queries because the values
are opaque to the planner.
Can you provide us with the output of explain analyze of that query?
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2010-04-06 18:48:32 | Re: Using high speed swap to improve performance? |
Previous Message | Robert Haas | 2010-04-06 18:33:51 | Re: LIMIT causes planner to do Index Scan using a less optimal index |