Mark Kirkwood <[EMAIL PROTECTED]> writes:
> Hmmm ... so it's only the selectivity that is the same (sourced from
> index->amcostestimate which I am guessing points to btcostestimate), is
> that correct?
No, the point is that btcostestimate will compute not only the same
selectivities but the ident
Tom Lane wrote:
Mark Kirkwood <[EMAIL PROTECTED]> writes:
the costs of paths using these indexes are
quite similar, so are quite sensitive to (some) parameter values.
They'll be exactly the same, actually, as long as the thing predicts
exactly one row retrieved. So it's quasi-random which plan yo
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> I happen to have some debugging code enabled for the optimizer, and the
> issue appears to be that the costs of paths using these indexes are
> quite similar, so are quite sensitive to (some) parameter values.
They'll be exactly the same, actually, as lo
Ragnar Hafstað wrote:
it is not rational to have random_page_cost < 1.
I agree, in theory one should never *need* to set it < 1. However in
cases when the optimizers understanding of things is a little off,
compensation may be required to achieve better plans (e.g. encouraging
index scans on data
On Thu, 2005-01-13 at 12:14 +1300, Mark Kirkwood wrote:
[snip some explains]
>
> I have random_page_cost = 0.8 in my postgresql.conf. Setting it back to
> the default (4) results in a plan using test_id1.
it is not rational to have random_page_cost < 1.
if you see improvement with such a setti
Litao Wu Wrote:
explain analyze
SELECT module, sum(action_deny)
FROM test
WHERE created >= ('now'::timestamptz - '1
day'::interval) AND customer_id='100'
AND domain='100'
GROUP BY module;
Here is my output for this query:
QUERY PLA
Litao Wu wrote:
Hi All,
Here is my test comparison between Postgres (7.3.2)
optimizer vs Oracle (10g) optimizer.
It seems to me that Postgres optimizer is not smart
enough.
Did I miss anything?
Yeah, 7.4.
7.3.2 is *ancient*. Here's output from 7.4:
[EMAIL PROTECTED] explain analyze
test-# SELEC
