On Thu, Jul 14, 2011 at 6:22 PM, Simon Riggs
<simon@2ndquadrant.com> wrote:
On Thu, Jul 14, 2011 at 4:57 PM, Pavan Deolasee
> Thanks Simon for looking at the patch.
Sorry, I didn't notice there was a patch attached. Not reviewed it. I
thought we were still just talking.
No problem. Please review it when you have time.
> I am not sure if the use case is really narrow.
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. So we still want to do vacuum in the most efficient way.
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.
I have great faith in your talents, just not sure about this
particular use of them.
Not sure if thats a compliment or a criticism :-)
I'm sorry to voice them now you've written the
patch.
Yeah, I would have liked if you would have said this earlier, but I appreciate comments any time.
Thanks,
