On Thu, Mar 24, 2016 at 4:51 AM, Stephen Frost <sfrost@snowman.net> wrote:
David, * David G. Johnston (david.g.johnston@gmail.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.
