Anastasia Lubennikova <lubennikovaav@gmail.com> writes:
> 2015-03-24 18:01 GMT+04:00 Tom Lane <tgl@sss.pgh.pa.us>:
>> I wonder whether it'd be possible to teach GIN to support index_getnext
>> instead. Initially it would probably work only for cases where the
>> index didn't have to return any columns ... but if we did it, maybe the
>> door would be open to cases where GIN could reconstruct actual values.
> Another idea is to write index_getnext() for GIN which would return some
> fake tuple. Since there is no difference for COUNT aggregate what the tuple
> contains. COUNT just wants to know whether we have tuple that satisfy the
> qual.
Well, yeah, that would be the idea (at least initially). You don't have
to return any real data unless you claim you can do so via amcanreturn.
The planner is still capable of selecting an index-only scan as long as
the query retrieves no columns.
The trick would be to not return the same heap TID more than once per
scan. A zero-order implementation would be to construct the same bitmap
we do now and then just provide a gingetnext function that scans through
that. That would be pretty awful in terms of scan startup time, so doing
better would be nice; but perhaps it would be useful even in that form.
regards, tom lane
