Re: Have vacuum emit a warning when it runs out of maintenance_work_mem - Mailing list pgsql-patches

From Heikki Linnakangas
Subject Re: Have vacuum emit a warning when it runs out of maintenance_work_mem
Date
Msg-id 4646E544.7020706@enterprisedb.com
Whole thread Raw
In response to Re: Have vacuum emit a warning when it runs out of maintenance_work_mem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Have vacuum emit a warning when it runs out of maintenance_work_mem  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.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.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

pgsql-patches by date:

Previous
From: Greg Smith
Date:
Subject: Re: Automatic adjustment of bgwriter_lru_maxpages
Next
From: Heikki Linnakangas
Date:
Subject: Re: Have vacuum emit a warning when it runs out of maintenance_work_mem