Thanks for the reply, Tom.
After tracing through this I see that the problem is that we don't have
> statistics for inheritance trees, and so you're getting a default
> estimate for the selectivity of the join condition.
>
I might be wrong but I suspect that the inheritance is not the only reason
"Vyacheslav Kalinin" <[EMAIL PROTECTED]> writes:
> Here is the reproduce code:
After tracing through this I see that the problem is that we don't have
statistics for inheritance trees, and so you're getting a default
estimate for the selectivity of the join condition. I'm not sure why
the similar
This is 8.3.0.
Here is the reproduce code:
create table contacts (
cid integer primary key,
pid integer not null,
cpid integer
);
create index ix_contacts_pid on contacts (pid);
create index ix_contacts_cpid on contacts (cpid);
create table pinfo (
pid integer,
constraint pk_pinfo pri
"Vyacheslav Kalinin" <[EMAIL PROTECTED]> writes:
> How come that outermost join expects 1515 rows given the row estimations of
> the inner and outer nested loop's parts?
I couldn't reproduce such a problem. What PG version are you running?
regards, tom lane
--
Sent via
Hello,
Consider two tables:
contacts:
cid integer primary key,
pid integer not null,
cpid integer
...
pinfo:
pid integer,
...
pinfo is a parent table with two partitions pinfo_p00 and pinfo_p01, all
three have primary keys on pid and partitions have proper constraints
that guarantee
