Robert Haas <robertmh...@gmail.com> writes: > On Thu, Feb 12, 2009 at 1:42 PM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers