isplay full headers for one
of the list messages to get the instructions from there.
--
Nolan Cafferky
Software Developer
IT Department
RBS Interactive
[EMAIL PROTECTED]
ed)
OR (f.PropertyId = g.PropertyId AND f.p_Modified_Date =
g.p_LastModified))
-- Luckys
--
Nolan Cafferky
Software Developer
IT Department
RBS Interactive
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: if posting/reading th
Tom Lane wrote:
Nolan Cafferky <[EMAIL PROTECTED]> writes:
But, I'm guessing that random_page_cost = 1 is not a realistic value.
Well, that depends. If all your data can be expected to fit in memory
then it is a realistic value. (If not, you should be real car
Tom Lane wrote:
The first-order knob for tuning indexscan vs seqscan costing is
random_page_cost. What have you got that set to?
This is currently at the default of 4. All of my other planner cost
constants are at default values as well. Dropping it to 1 drops the
estimated cost by a compa
Questions:
* What can I do to reduce the estimated row count on the query?
* Why does clustering drive down the estimated cost for the index scan
so much? Does a change in correlation from .72 to 1 make that much of
a difference?
* Can I convince my query planner to index scan without clustering
I'm running postgres 8.0.7, and I've got a table of orders with about
100,000 entries. I want to just look at the new orders, right now 104 of
them.
EXPLAIN ANALYZE
SELECT
order_id
FROM
orders
WHERE
order_statuses_id = (SELECT id FROM order_statuses WHERE id_name
= 'new'
