should readings in DB be 32 or 64 bit real number?

[huss]

Is your feature request related to a problem? Please describe.

PR #357 changed the stored readings values from integer to real. It uses real (32-bit values) whereas other places in OED used float (64-bit values). Except for space and access speed changes, it would seem float is better. One concern is that we actually truncate readings input into OED if they exceed the real accuracy. A second is that we do calculations on the data so the final error in what is shown could be larger. This is an issue to start a discussion of whether having only 6 decimal digits of reading accuracy is an issue for sites, and, if so, to investigate making the change to float that gives 15 digits.

Describe the solution you'd like

In terms of space, each reading now takes up 4 + 2 * 8 (two dates at 8 bytes each) = 20 and it would become 8 + 2 * 8 = 24 or around a 20% increase. Given raw readings are usually not accessed too often and disk space is not a premium at many sites, this might be reasonable to do. However, testing of speed and disk space should be done. Also, others may see potential consequences to the change. If we decide this is a good idea, the actual change is not bad as it means changing the reading table creation and creating a migration (see below on that).

Describe alternatives you've considered

As indicated above, this is not directly breaking anything. We could leave as is.

Additional context

PR #651 changes the meter table to float but this takes very little space and isn't accessed too often.

Note that the change will have to be done carefully for the migration because a quick test found that Postgres will not let you alter the numeric since it is used in view calculations.

[huss]

I note that the daily readings view used double precision (64-bit) and the new hourly readings view does the same. Given this, I think the readings should change to 64-bit/double precision unless someone gives a reason not to. The reading table is in src/server/sql/reading/create_readings_table.sql.

[huss]

This was completed with PR #776 but did not close.