Re: a fast bloat measurement tool (was Re: Measuring relation free space) - Mailing list pgsql-hackers

From Abhijit Menon-Sen
Subject Re: a fast bloat measurement tool (was Re: Measuring relation free space)
Date
Msg-id 20141226073834.GA24858@toroid.org
Whole thread Raw
In response to Re: a fast bloat measurement tool (was Re: Measuring relation free space)  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Responses Re: a fast bloat measurement tool (was Re: Measuring relation free space)
Re: a fast bloat measurement tool (was Re: Measuring relation free space)
List pgsql-hackers
At 2014-09-25 15:40:11 +0530, ams@2ndQuadrant.com wrote:
>
> All right, then I'll post a version that addresses Amit's other
> points, adds a new file/function to pgstattuple, acquires content
> locks, and uses HeapTupleSatisfiesVacuum, hint-bit setting and all.

Sorry, I forgot to post this patch. It does what I listed above, and
seems to work fine (it's still quite a lot faster than pgstattuple
in many cases).

A couple of remaining questions:

1. I didn't change the handling of LP_DEAD items, because the way it is
   now matches what pgstattuple counts. I'm open to changing it, though.
   Maybe it makes sense to count LP_DEAD items iff lp_len != 0? Or just
   leave it as it is? I think it doesn't matter much.

2. I changed the code to acquire the content locks on the buffer, as
   discussed, but it still uses HeapTupleSatisfiesVacuum. Amit suggested
   using HeapTupleSatisfiesVisibility, but it's not clear to me why that
   would be better. I welcome advice in this matter.

   (If anything, I should use HeapTupleIsSurelyDead, which doesn't set
   any hint bits, but which I earlier rejected as too conservative in
   its dead/not-dead decisions for this purpose.)

(I've actually patched the pgstattuple.sgml docs as well, but I want to
re-read that to make sure it's up to date, and didn't want to wait to
post the code changes.)

I also didn't change the name. I figure it's easy enough to change it
everywhere once all the remaining pieces are in place.

Comments welcome.

-- Abhijit

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: The return value of allocate_recordbuf()
Next
From: Teodor Sigaev
Date:
Subject: Re: btree_gin and ranges