Thomas: On Fri, Mar 22, 2019 at 2:03 PM Thomas Güttler <guettliml@xxxxxxxxxxxxxxxxxx> wrote: > > I'm not too sure, but I read ( in the code ) you are measuring a > > nearly not compressible urandom data againtst a highly compressible ( ... > for this case toast-tables/wal is a detail of the implementation. > This tests does not care about the "why it takes longer". It just generates > a performance chart. > Yes, it does exactly what you say: it compares > nearly not compressible urandom data against a highly compressible data. > In my case, will get nearly random data (binary PDF, JPG, ...). And that's why > I wanted to benchmark it. Well, if all you wanted is to benchmark, a performance chart, you know it. I assumed you wanted to know more, like where the bottleneck is and how to try to avoid it. My fault. I was specifically confused because, IIRC, you said ascii data took much longer than binary, which is a completely different test ( you can test ascii vs binary by generating chunks of random numbers in say, the 0 to 127 and sending that data once as is and once more shifting left by one every byte. That should test ascii-binary differences, but if you test random vs uniform I think the problem is in the randomness, you could just test sending '\x92'*i, or something similar, but if you are just interested in the benchmark, you have it done. Just one thing, a single graph with two labels "ascii" and "random" is misleading, as constant/random is orthogonal with ascii/binary, but as I said, my fault, all the text about psycopg and other stuff led me to think you wanted some kind of diagnosis and improvements. Regards.
