"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> On 9/11/07, Bruce Momjian <bruce@momjian.us> 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
