Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Feb 10, 2009 at 10:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> It strikes me that part of the issue here is that the behavior of this
>> code is much better adapted to the bitmap-scan API than the traditional
>> indexscan API. Since GIN doesn't support ordered scan anyway, I wonder
>> whether it wouldn't be more sensible to simply allow it to not offer
>> the traditional API. It should be easy to make the planner ignore plain
>> indexscan plans for an AM that didn't support them.
> If that doesn't lead to a performance degradation, I think it would be
> a good idea.
For queries that select only a single index entry, there might be some
speed degradation, but a quick test suggests it's in the
single-digit-percentage range if everything's cached; and of course if
you have to go to disk then the extra CPU cycles to push a bitmap around
are lost in the noise.
In any case, as a wise man once said "I can make this code arbitrarily
fast, if it doesn't have to give the right answer". Blowing up in easily
foreseeable circumstances isn't my idea of giving the right answer.
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
