"Noah M. Daniels" <[EMAIL PROTECTED]> writes:
> You're right; this is postgres 8.0.8. Perhaps upgrading will solve
> this issue. Is there any way to get this query to perform better in
> postgres 8.0.8?
You could try reducing random_page_cost, but I'm not sure that will
help much.
Tom,
You're right; this is postgres 8.0.8. Perhaps upgrading will solve
this issue. Is there any way to get this query to perform better in
postgres 8.0.8?
thanks!
On Mar 23, 2007, at 6:13 PM, Tom Lane wrote:
"Noah M. Daniels" <[EMAIL PROTECTED]> writes:
I have two queries that are very
"Noah M. Daniels" <[EMAIL PROTECTED]> writes:
> I have two queries that are very similar, that run on the same table
> with slightly different conditions. However, despite a similar number
> of rows returned, the query planner is insisting on a different
> ordering and different join algorith
Not much of a difference, unfortunately... I still wonder why it's
doing the 'supplier' (slow) query using the merge right join.
the 'fast' query:
Nested Loop Left Join (cost=0.00..423342.71 rows=2481 width=410)
(actual time=100.076..6380.865 rows=1355 loops=1)
-> Index Scan using index
Run VACUUM ANALYZE and see if the cost estimates became close to the
effective rows. This could make it faster.
2007/3/23, Noah M. Daniels <[EMAIL PROTECTED]>:
SLOW:
Merge Right Join (cost=1138.78..460482.84 rows=2993 width=405)
(actual time=1244745.427..1245714.571 rows=39 loops=1)
Merge Co
Hi,
I have two queries that are very similar, that run on the same table
with slightly different conditions. However, despite a similar number
of rows returned, the query planner is insisting on a different
ordering and different join algorithm, causing a huge performance
hit. I'm not sur
