On Tue, Dec 22, 2015 at 10:45 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote:
> Hi > > 2015-12-21 16:11 GMT+01:00 Robert Haas <robertmh...@gmail.com>: > >> On Sun, Dec 20, 2015 at 4:54 AM, Pavel Stehule <pavel.steh...@gmail.com> >> wrote: >> > new update: >> > >> > 1. unit searching is case insensitive >> > >> > 2. initial support for binary byte prefixes - KiB, MiB, .. (IEC >> standard), >> > change behave for SI units >> > >> > Second point is much more complex then it is looking - if pg_size_bytes >> > should be consistent with pg_size_pretty. >> > >> > The current pg_size_pretty and transformations in guc.c are based on >> JEDEC >> > standard. Using this standard for GUC has sense - using it for object >> sizes >> > is probably unhappy. >> > >> > I tried to fix (and enhance) pg_size_pretty - now reports correct >> units, and >> > via second parameter it allows to specify base: 2 (binary, IEC - >> default) >> > or 10 (SI). >> >> -1 from me. I don't think we should muck with the way pg_size_pretty >> works. >> > > new update - I reverted changes in pg_size_pretty > Hi, I didn't check out earlier versions of this patch, but the latest one still changes pg_size_pretty() to emit PB suffix. I don't think it is worth it to throw a number of changes together like that. We should focus on adding pg_size_bytes() first and make it compatible with both pg_size_pretty() and existing GUC units: that is support suffixes up to TB and make sure they have the meaning of powers of 2^10, not 10^3. Re-using the table present in guc.c would be a plus. Next, we could think about adding handling of PB suffix on input and output, but I don't see a big problem if that is emitted as 1024TB or the user has to specify it as 1024TB in a GUC or argument to pg_size_bytes(): an minor inconvenience only. -- Alex
