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

Reply via email to