Hello
I test using index on foreign key. I found situation, when planner choose
worse plan.
create table f1(pk serial primary key);
create table f2(fk integer references f1(pk));
insert into f1 select a from generate_series(1,1) a;
insert into f2 select (random()*)::int+1 from
On Tue, May 16, 2006 at 11:52:05AM +0200, Pavel Stehule wrote:
Hello
I test using index on foreign key. I found situation, when planner choose
worse plan.
Can we seen an EXPLAIN ANALYZE output to see where the miscalculation
lies. Is it underestimating the cost of the index scan, or
Can we seen an EXPLAIN ANALYZE output to see where the miscalculation
lies. Is it underestimating the cost of the index scan, or
overestimating the cost of the hash join.
postgres= explain analyze select count(*) from f1 join f2 on pk=fk;
On Tue, May 16, 2006 at 12:54:58PM +0200, Pavel Stehule wrote:
Can we seen an EXPLAIN ANALYZE output to see where the miscalculation
lies. Is it underestimating the cost of the index scan, or
overestimating the cost of the hash join.
postgres= explain analyze select count(*) from f1 join f2
These are all minor abberations though, on the whole the estimates are
pretty good. Perhaps you need to tweak the values of random_page_cost
and similar variables.
Thank You, It's general problem or only mine? I have 100% standard current
PC.
Pavel
These are all minor abberations though, on the whole the estimates
are
pretty good. Perhaps you need to tweak the values of random_page_cost
and similar variables.
Thank You, It's general problem or only mine? I have 100%
standard current PC.
The default random_page_cost assumes some
These are all minor abberations though, on the whole the estimates
are
pretty good. Perhaps you need to tweak the values of random_page_cost
and similar variables.
Thank You, It's general problem or only mine? I have 100%
standard current PC.
The default random_page_cost assumes some
