Re: Freeze avoidance of very large table.
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: Freeze avoidance of very large table. |
Дата | |
Msg-id | 20160303.150656.156862924.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: Freeze avoidance of very large table. (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Список | pgsql-hackers |
At Wed, 2 Mar 2016 17:57:27 -0600, Jim Nasby <Jim.Nasby@BlueTreble.com> wrote in <56D77DE7.7080309@BlueTreble.com> > On 3/2/16 5:41 PM, Tom Lane wrote: > > Jim Nasby <Jim.Nasby@BlueTreble.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
В списке pgsql-hackers по дате отправления: