On Mon, Oct 7, 2019 at 09:40:22PM +0200, Tomas Vondra wrote: > On Mon, Oct 07, 2019 at 10:22:22AM -0400, Bruce Momjian wrote: > > > So essentially the argument is - if you have hw crypto acceleration (aka > > > AES-NI), then the overhead of all-cluster encryption is so low it does > > > not make sense to bother with lowering it with column encryption. > > > > Yes, I think that is true. Column-level encryption can be useful in > > giving different people control of the keys, but I think that feature > > should be developed at the SQL level so clients can unlock the key and > > backups include the encryption keys. > > > > FWIW that's not how the column encryption (at least in Oracle works). It > uses the same encryption keys (with 2-tier key architecture), and the > keys are stored in a wallet. The user only supplies a passphrase (well, > a DBA does that, because it happens only once after the instance starts). > > Not sure what exactly you mean by "SQL level" but I agree it's clearly > much higher up the stack than encryption at the block level.
Right, what I was saying is that column encryption where they keys are unlocked by the administrator are really only useful to reduce encryption overhead, and I think we will find it just isn't worth the API complexity to allow that. Per-user keys are useful for cases beyond performance, but require SQL-level control. > > > IMO that's a good argument against column encryption (at least when used > > > to reduce overhead), although 10% still quite a bit. > > > > I think that test was a worst-case one and I think it needs to be > > optimized before we draw any conclusions. > > What test? I was really referring to the PDF, which talks about 10% > threshold for the tablespace encryption. And in another section it says > > Internal benchmark tests and customers reported a performance impact of 4 > to 8% in end-user response time, and an increase of 1 to 5% in CPU usage. > > Of course, this is not on PostgreSQL, but I'd expect to have comparable > overhead, despite architectural differences. Ultimately, even if it's 15 > or 20%, the general rule is likely to remain the same, i.e. column > encryption has significantly higher overhead, and can only beat > tablespace encryption when very small fraction of columns is encrypted. Right, and I doubt it will be worth it, but I think we need to complete all-cluster encryption and then run some tests so see what the overhead is. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
