On 25.06.2013 21:18, Alexander Korotkov wrote:
On Tue, Jun 25, 2013 at 7:31 PM, Heikki Linnakangas<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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
