|From:||Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>|
|Subject:||Re: a fast bloat measurement tool (was Re: Measuring relation free space)|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
I've attached an updated patch for pgstatbloat, as well as a patch to
replace two uses of BuildTupleFromCStrings() elsewhere in pgstattuple.
I've made the changes you mentioned in your earlier mail, except that I
have not changed the name pending further suggestions about what would
be the best name.
At 2015-05-09 15:36:49 +0530, ams(at)2ndQuadrant(dot)com wrote:
> At 2015-05-09 02:20:51 +0200, andres(at)anarazel(dot)de wrote:
> > I haven't checked, but I'm not sure that it's safe/meaningful to
> > call PageGetHeapFreeSpace() on a new page.
> OK, I'll check and fix if necessary.
You're right, PageGetHeapFreeSpace() isn't safe on a new page. I've
added a guard to that call in the attached patch, but I'm not sure
that's the right thing to do.
Should I copy the orphaned new-page handling from lazy_scan_heap? What
about for empty pages? Neither feels like a very good thing to do, but
then neither does skipping the new page silently. Should I count the
space it would have free if it were initialised, but leave the page
alone for VACUUM to deal with? Or just leave it as it is?
|Next Message||Robert Haas||2015-05-11 11:56:34||Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)|
|Previous Message||Thom Brown||2015-05-11 08:49:24||Re: pgsql: Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.|