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