Re: Freeze avoidance of very large table.

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: Jim(dot)Nasby(at)BlueTreble(dot)com
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pg(at)heroku(dot)com, robertmhaas(at)gmail(dot)com, sawada(dot)mshk(at)gmail(dot)com, bruce(at)momjian(dot)us, alvherre(at)2ndquadrant(dot)com, michael(dot)paquier(at)gmail(dot)com, jeff(dot)janes(at)gmail(dot)com, amit(dot)kapila16(at)gmail(dot)com, andres(at)anarazel(dot)de, simon(at)2ndquadrant(dot)com, josh(at)agliodbs(dot)com, masao(dot)fujii(at)gmail(dot)com, petr(at)2ndquadrant(dot)com, stark(at)mit(dot)edu, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Freeze avoidance of very large table.
Date: 2016-03-03 06:06:56
Message-ID: 20160303.150656.156862924.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 2 Mar 2016 17:57:27 -0600, Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> wrote in <56D77DE7(dot)7080309(at)BlueTreble(dot)com>
> On 3/2/16 5:41 PM, Tom Lane wrote:
> > Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> >> On 3/2/16 4:21 PM, Peter Geoghegan wrote:
> >>> I think you should commit this. The chances of anyone other than you
> >>> and Masahiko recalling that you developed this tool in 3 years is
> >>> essentially nil. I think that the cost of committing a developer-level
> >>> debugging tool like this is very low. Modules like pg_freespacemap
> >>> currently already have no chance of being of use to ordinary users.
> >>> All you need to do is restrict the functions to throw an error when
> >>> called by non-superusers, out of caution.
> >>>
> >>> It's a problem that modules like pg_stat_statements and
> >>> pg_freespacemap are currently lumped together in the documentation,
> >>> but we all know that.
> >
> >> +1.
> >
> > Would it make any sense to stick it under src/test/modules/ instead of
> > contrib/ ? That would help make it clear that it's a debugging tool
> > and not something we expect end users to use.
>
> I haven't looked at it in detail; is there something inherently
> dangerous about it?

I don't see any danger but the interface doesn't seem to fit use
by DBAs.

> When I'm forced to wear a DBA hat, I'd really love to be able to find
> out what VM status for a large table is. If it's in contrib they'll
> know the tool is there; if it's under src then there's about 0 chance
> of that. I'd think SU-only and any appropriate warnings would be
> enough heads-up for DBAs to be careful with it.

It looks to expose nothing about table contents. At lesast
anybody who can see the name of a table are safely allowable to
use this on it.

A possible usage (for me) of this would be directly couting
(un)vacuumed or (un)freezed pages in a relation. It would be
convenient that the 'freezed' and 'vacuumed' bits are in separate
integers. It would be usable even stats values for these bits are
shown in statistics views.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-03-03 06:10:58 Re: postgres_fdw vs. force_parallel_mode on ppc
Previous Message Oleg Bartunov 2016-03-03 05:55:05 Re: SP-GiST support for inet datatypes