On 2/20/18 05:06, Fabien COELHO wrote: >> Now the overhead is really 60-65%. Although the specification is >> unambiguous, >> but we still need some maths to know whether it fits in buffers or memory... >> The point of Karel regression is to take this into account. >> >> Also, whether this option would be more admissible to Tom is still an open >> question. Tom? > > Here is a version with this approach: the documentation talks about > "actual data size, without overheads", and points out that storage > overheads are typically an additional 65%.
I think when deciding on a size for a test database for benchmarking, you want to size it relative to RAM or other storage layers. So a feature that allows you to create a database of size N but it's actually not going to be anywhere near N seems pretty useless for that. (Also, we have, for better or worse, settled on a convention for byte unit prefixes in guc.c. Let's not introduce another one.) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
