* Michael Paquier (michael.paqu...@gmail.com) wrote: > Do you have real numbers about the performance impact that this module > has when plugged in the server? If yes, it would be good to get an > idea of how much audit costs and if it has a clear performance impact > this should be documented to warn the user. Some users may really need > audit features as you mention, but the performance drop could be an > obstacle for others so they may prefer continue betting on performance > instead of pgaudit.
While these performance numbers would be interesting, I don't feel it's necessary to consider the performance of this module as part of the question about if it should go into contrib or not. > Where are we on this? This patch has no activity for the last two > months... So marking it as returned with feedback. It would be good to > see actual numbers about the performance impact this involves. What I was hoping to see were the changes that I had suggested up-thread, but I discovered about a week or two ago that there was a misunderstanding between at least Abhijit and myself about what was being suggested. For the sake of the archives, the idea I had been trying to propose is to use a role's permissions as a mechanism to define what should be audited. An example is: The magic "audit" role has SELECT rights on a given table. When any user does a SELECT against that table, ExecCheckRTPerms is called and there's a hook there which the module can use to say "ok, does the audit role have any permissions here?" and, if the result is yes, then the command is audited. Note that this role, from core PG's perspective, wouldn't be special at all; it would just be that pgaudit would use the role's permissions as a way to figure out if a given command should be audited or not. That's not to say that we couldn't commit pgaudit without this capability and add it later, but I had been expecting to see progress along these lines prior to reviewing it. Thanks, Stephen
signature.asc
Description: Digital signature