Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Or we could switch to a more compact representation of the dead tuples,
and not need such a big maintenance_work_mem in the first place.
Hm, you got any ideas? One constraint is that it doesn't seem
acceptable to make the search function any slower.
That's the biggest problem.
One idea is to use a compressed bitmap like in the bitmap index patch,
and a tree of block numbers or ranges to allow random access to it.
Another idea is to use the current array representation, but instead of
storing a item pointer on every slot, you store either a normal item
pointer, or three extra offsets on the previous block. To make the
binary search work, set the high bit (which isn't used otherwise) of the
extra offsets to tell them apart from normal item pointers. When the
binary search lands on those extra offsets, scan backwards to the
closest normal item to get the block number.
Performance is a bit hard to predict. A more compact representation
might be more cache-efficient, which might offset the cost of a more
complex search function.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
