"Pavan Deolasee" <[EMAIL PROTECTED]> writes: > On 9/11/07, Bruce Momjian <[EMAIL PROTECTED]> wrote: > >> Right. My point is that pruning only modifies item pointers. It does >> not change the actual heap tuples. In the quote above, how is Heikki's >> "quick pruning" different from the pruning you are describing? > > I think the only difference is that the quick pruning does not mark > intermediate tuples ~LP_USED and hence we may avoid WAL logging. > > Btw, I am not too enthusiastic about quick pruning because it leaves > behind dead heap-only tuples which are not reachable from any root > heap tuples. Not that we can't handle them, but I am worried about > making such changes right now unless we are sure about the benefits. > We can always tune and tweak in 8.4
You could mark such tuples with LP_DELETE. That would also let other transactions quickly tot up how much space would be available if they were to run PageRepairFragmentation. But if you don't WAL log setting LP_DELETE then you would still have to deal with unreachable HOT tuples who lost their LP_DELETE flag. I suppose that as long as PageRepairFragmentation first looks for any dead HOT tuples without depending on LP_DELETE that would be enough. I wonder if you could do the quick prune without even taking the exclusive page lock? You're overwriting 16 bits and you know nobody else will be modifying any of the line pointers in question to anything else. (because your pin prevents the vacuum lock from coming in and trying to mark it unused). -- Gregory Stark 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