Re: Only owners can ANALYZE tables...seems overly restrictive

On Thu, Mar 24, 2016 at 4:51 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> David,
>
> * David G. Johnston (david(dot)g(dot)johnston(at)gmail(dot)com) wrote:
> > Which means that, aside from effort, the main blocking factors here are
> > code complexity (which I understand) and limited grant "bits" as Stephen
> > puts it. So I pose the question: do any of the committers consider a
> grant
> > bit too valuable to consume on an ANALYZE grant?
>
> I wasn't referring to "bits" as "things" to do but rather as actual
> zeros and ones- AclMode is a 32bit integer, of which the bottom half are
> 'regular' grantable rights and the top half are "with grant option"
> indications, meanly we've only got 16 to work with, and every object
> uses AclMode, so we have to support *all* kinds of GRANTs with those 16
> bits.
>

​Yes, that is how I understood "bits"...sorry for the poor phrasing.​

> See src/include/nodes/parsenodes.h, around line 63.
>
> > If that and/or general code complexity means this will not be added even
> if
> > a patch was proposed for 9.7 then I'll move on and institute one of the
> > hacks that has been proffered. Otherwise I have (more than) half a mind
> to
> > find some way to get a patch written.
>
> I don't see any reason why the patch itself would be terribly difficult,
> but are we sure we'd want just ANALYZE and not VACUUM also? Which would
> have to be another bit, since those are pretty different actions.
>
>
In the limited experience that​ prompted this requested the benefit of
performing a VACUUM is significantly less than the benefit of performing
ANALYZE, and the cost of the former is considerably higher. I'm quite
content to leave VACUUM decisions to the auto-vacuum process which balances
the benefit of removing bloat with the I/O cost of doing so.

The question really is- what other things might we want as grantable
> rights in the future? Once these 16 bits are gone, it's a whole bunch
> of work to get more.
>

If I am reading parsenodes.h correctly we presently use only 12 of 16 bits
and those that are present all seem ancient. With no other existing need
to add a single additional grantable option, let alone 4, I'm not see this
as being particularly concerning.

Let someone else argue for inclusion of VACUUM before considering adding it
- all I believe that we need is ANALYZE. I want programs doing ETL to be
able to get the system into "good-enough" shape to be functional;
maintenance processes can deal with the rest.

David J.