On Sun, Jun 30, 2013 at 3:09 PM, Heikki Linnakangas <hlinnakan...@vmware.com > wrote:
> On 25.06.2013 21:18, Alexander Korotkov wrote: > >> On Tue, Jun 25, 2013 at 7:31 PM, Heikki Linnakangas<hlinnakangas@** >> vmware.com <hlinnakan...@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. > Yes, I think we should have two distinct opclasses. ------ With best regards, Alexander Korotkov.
