|From:||Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>|
|To:||Andres Freund <andres(at)2ndquadrant(dot)com>|
|Cc:||Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: a fast bloat measurement tool (was Re: Measuring relation free space)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
At 2014-09-25 15:40:11 +0530, ams(at)2ndQuadrant(dot)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.
|Next Message||Teodor Sigaev||2014-12-26 10:33:26||Re: btree_gin and ranges|
|Previous Message||Fujii Masao||2014-12-26 07:31:07||The return value of allocate_recordbuf()|