On 25.06.2013 21:18, Alexander Korotkov wrote:
> On Tue, Jun 25, 2013 at 7:31 PM, Heikki Linnakangas<hlinnakangas@vmware.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.
I'm marking this as "returned with feedback", as we need new performance
testing from I/O point of view. The comparison should be with the base
"additional information" patch or at least the part of that that packs
the item pointers more tightly. Also, this depends on the additional
information patch, so we need to get that committed before this one, and
I just returned that patch.
- Heikki