Re: GIN improvements part 3: ordering in index

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.