Re: GIN fast insert

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Feb 12, 2009 at 1:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> So? Barring some evidence that there's a significant performance win
>> from a conventional indexscan, this is a weak argument. AFAICS the only
>> significant advantage of the conventional API is to support ordered
>> scans, and GIN doesn't do that anyway.

> Wouldn't it force you to recheck all tuples on the page, instead of
> just rechecking the one of interest?

In the scenario at hand you'd have to do that anyway.

Bear in mind that if the query is predicted to return more than a few
rows, the planner is always going to pick bitmap scan anyway. So this
whole issue is really only going to arise when you have a very bad
rowcount prediction (or a very stale plan), leading to a choice of
indexscan plan followed by enough rows actually returned to make the TID
bitmap become lossy. That's certainly within the realm of possibility,
particularly since we often don't have good estimators for
GIN-compatible operators. But I think designing to squeeze every last
bit of performance out of the case is a mistake. We should be satisfied
to have correctness.

In the end this is a tradeoff: how much complexity and loss of
maintainability are we willing to accept to squeeze out a bit more
performance? I'm leaning to the KISS end of that choice. The tests
I did yesterday suggested to me that it would be difficult even to
measure a performance gain from supporting conventional indexscan in
GIN. IMHO the kinds of schemes that are being tossed around here are
not remotely sane to choose if they don't lead to *big* wins.

regards, tom lane