Re: a fast bloat measurement tool (was Re: Measuring relation free space)

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: a fast bloat measurement tool (was Re: Measuring relation free space)
Date: 2014-09-25 09:41:29
Message-ID: 20140925094129.GB16581@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-09-25 10:24:39 +0530, Abhijit Menon-Sen wrote:
> At 2014-09-24 11:09:24 +0200, andres(at)2ndquadrant(dot)com wrote:
> > I think it's completely unacceptable to copy a visibility routine.
>
> OK. Which visibility routine should I use, and should I try to create a
> variant that doesn't set hint bits?

I've not yet followed your premise that you actually need one that
doesn't set hint bits...

> I don't have any reasoning for why it's safe to not hold a content lock.
> If there is one, I need help to find it. If not, I'll acquire a content
> lock. (If anyone can explain why it isn't safe, I would appreciate it.)

I don't see why it'd be safe. Without the content lock you can come
across half written tuple headers and similar things. You can try to
argue that all the possible faults of that are harmless, but I think
that'd require a tremendous amount of code review and it'd be hard to
continue to guarantee. There's a reason we acquire locks, you know :)

I think it's saner to first get this working & committed properly *with*
the lock. If you afterwards have energy to improve it further we can
another look.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Abhijit Menon-Sen 2014-09-25 10:10:11 Re: a fast bloat measurement tool (was Re: Measuring relation free space)
Previous Message Heikki Linnakangas 2014-09-25 09:12:45 Re: Selectivity estimation for inet operators