On Fri, Jul 15, 2011 at 12:56 AM, Pavan Deolasee
<pavan.deolasee@gmail.com> wrote:
> On Thu, Jul 14, 2011 at 6:22 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> This is a very rare issue, because of all the work yourself and Heikki
>> have put in.
>>
>
> I don't think its rare case since vacuum on any table, small or large, would
> take two passes today. Avoiding one of the two, would help the system in
> general. HOT and other things help to a great extent, but unfortunately they
> don't make vacuum completely go away.
I don't really believe that. To progress this I think we need a clear
test case that we can judge this patch against. Building that will
show quite how rarely this is a problem.
>> It's only important when we have a (1) big table (hence long scan
>> time), (2) a use case that avoids HOT *and* (3) we have dirtied a
>> large enough section of table that the vacuum map is ineffective and
>> we need to scan high % of table. That combination is pretty rare, so
>> penalising everybody else with 8 bytes per block seems too much to me.
>>
>
> The additional space is allocated only for those pages which has dead-vacuum
> line pointers and would stay only till the next HOT-prune operation on the
> page. So everybody does not pay the penalty, even if we assume its too much
> and if thats what worries you most.
OK, that's the winner. If you're only doing this when it really does
matter then I'm happy.
My additional requests would be that we can easily tell which blocks
have been modified like this, that we have a way to turn this off if
we get bugs for next few releases, that we check it all works with Hot
Standby just fine and that all the block inspection tools support it.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
