On Mon, Feb 29, 2016 at 6:31 AM, Stephen Frost <sfr...@snowman.net> wrote:
> * David G. Johnston (david.g.johns...@gmail.com) wrote: > > Given the amount of damage a person with write access to a table can get > > into it seems pointless to not allow them to analyze the table after > their > > updates - since best practices would say that normal work with a table > > should not be performed by an owner. > > > > I should the check for whether a given user can or cannot analyze a table > > should be whether the user has INSERT, UPDATE, or DELETE privileges. > > Realistically, ANALYZE is a background/maintenance task that autovacuum > should be handling for you. > Then my recent experience of adding a bunch of records and having the subsequent select query take forever because the table wasn't analyzed is not supposed to happen? What am I doing wrong then that autovacuum didn't run for me? > > I suppose row-level-security might come into play here... > > Yes, you may only have access to a subset of the table. > > TBH, since you cannot see the data being analyzed I don't see a security implication here if you allow someone to ANALYZE the whole table even when RLS is in place. If we had plenty more bits to allow ANALYZE to be independently > GRANT'able, then maybe, but those are a limited resource. > The planner and system performance seems important enough to give it such a resource. But as I stated initially I personally believe that a user with INSERT/DELETE/UPDATE permissions on a table (maybe require all three) should also be allowed to ANALYZE said table. David J.
