Re: GIN improvements part 3: ordering in index

On Sun, Jun 30, 2013 at 3:09 PM, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com
> wrote:

> On 25.06.2013 21:18, Alexander Korotkov wrote:
>
>> On Tue, Jun 25, 2013 at 7:31 PM, Heikki Linnakangas<hlinnakangas(at)**
>> vmware.com <hlinnakangas(at)vmware(dot)com>
>>
>>> wrote:
>>>
>>
>> In summary: The test case you presented as motivation for this patch is a
>>> bit of a worst-case scenario for the current tidbitmap implementation.
>>> The
>>> speedup from your patch comes from avoiding the tidbitmap. However, it
>>> would be fairly easy to optimize the tidbitmap to handle this scenario
>>> better, which would benefit all kinds of queries that use bitmap scans.
>>> There is really no reason to complicate the GIN API for this. Let's just
>>> optimize tidbitmap.
>>>
>>> I'm not sure if I fullly understand your patch, though. Is there some
>>> other test scenario where it performs significantly better, which can not
>>> be attributed to a tidbitmap overhead? I'm assuming 'no' for now, and
>>> marking this patch as rejected in the commitfest app, but feel free to
>>> reopen if there is.
>>>
>>
>> So, it's likely I've positioned this patch wrong from the begging, because
>> my examples were focused on CPU time improvement. But initial purpose of
>> this patch was to decrease IO.
>>
>
> Ok. Storing the additional information bloats the index considerably, so
> it's clearly not going to be a win in all cases. So whether you store the
> additional information or not needs to configurable somehow.
>

Yes, I think we should have two distinct opclasses.

------
With best regards,
Alexander Korotkov.