* David G. Johnston (david.g.johnston@xxxxxxxxx) 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.
