Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> 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.
In response to
pgsql-patches by date
|Next:||From: Heikki Linnakangas||Date: 2007-05-13 10:19:07|
|Subject: Re: Have vacuum emit a warning when it runs out of maintenance_work_mem|
|Previous:||From: Heikki Linnakangas||Date: 2007-05-13 06:54:20|
|Subject: Re: Performance monitoring|