Robert Haas <robertmh...@gmail.com> writes:
> Well, I do not understand this code in depth (can you tell?) but it
> seems to me that we are effectively computing the size of the inner
> relation in two different ways in two different parts of the code.
That's because we are considering two different definitions of the inner
relation: one that is stand-alone (the actual table size times the
selectivity of any non-join restriction clauses for that table), versus
one that is parameterized by means of applying an additional join clause
during the scan. It's entirely expected that the latter estimate will
be smaller. But that only applies to the number of rows produced by the
table scan; it should not affect our conclusions about how big the join
result is, because the same join clause is being used whether we do it
like this or as a regular join over an unparameterized table scan.
> Whatever logic the index-scan-path is using to estimate how many rows
> are going to pop out is obviously much more accurate - in this
> instance - than the join selectivity estimator.
The reason for that is that in 8.4 we don't have any good method for
making join selectivity estimates involving appendrels. That's not a
structural problem, just an omission in the selectivity support; which
has been rectified in 9.0 and up.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
