Re: [PATCH] Fix ScalarArrayOpExpr estimation for GIN indexes

Marti Raudsepp <marti(at)juffo(dot)org> writes:
> On Tue, Dec 20, 2011 at 07:08, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> but I think I don't
>> like this refactoring much. Will take a closer look tomorrow.

> I was afraid you'd say that, especially for a change that should be
> backpatched. But I couldn't think of alternative ways to do it that
> give non-bogus estimates.

I've applied a revised version of this patch that factors things in a
way I found nicer. The main concrete thing I didn't like about what
you'd done was dropping the haveFullScan logic. If we have more than
one qual triggering that, we're still going to do one full scan, not
multiples of that. It seemed unreasonably hard to get that exactly
right when there are multiple array quals each doing such a thing,
but I didn't want to let it regress in its handling of multiple
plain quals.

Also, while looking at this I realized that we had the costing of
nestloop cases all wrong. The idea is to scale up the number of
tuples (pages) fetched, apply index_pages_fetched(), then scale
down again. I think maybe somebody thought that was redundant,
but it's not because index_pages_fetched() is nonlinear.

regards, tom lane