Re: Startup cost of sequential scan

Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> I understand that startup cost is not "time to find the first row".
> But I think this example highlight not one but two issues.
> 1) Row count estimates for joins are wrong.

Yup.

> 2) Rows are assumed to be continuous while in reality they are
> discrete.

Where do you get that from?

The problem this example is highlighting is mostly just the bad
join size estimate, imo. It's not at all clear that the planner
would still do the wrong thing if that were fixed. In fact,
if I replace the contents of t2 with some other distribution,
such as
insert into t2 (select i from generate_series(1,100)i);
I get a much better join size estimate *and* a sane plan, even
in the LIMIT case. So the problem here is just with the join
size estimate.

regards, tom lane