Re: Tid scan improvements

On Thu, 14 Mar 2019 at 16:46, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
>
> The only possible risk I can foresee is that it may be more likely we
> underestimate the selectivity and that causes something like a nested
> loop join due to the estimation being, say 1 row.
>
> It could happen in a case like:
>
> SELECT * FROM bloated_table WHERE ctid >= <last ctid that would exist
> without bloat>
>
> but I don't think we should keep using DEFAULT_INEQ_SEL just in case
> this happens. We could probably fix 90% of those cases by returning 2
> rows instead of 1.

Thanks for looking at the patch David.

I'm not sure how an unreasonable underestimation would occur here. If
you have a table bloated to say 10x its minimal size, the estimator
still assumes an even distribution of tuples (I don't think we can do
much better than that). So the selectivity of "ctid >= <last ctid
that would exist without bloat>" is still going to be 0.9.

Edmund