You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since we will constantly insert data into this table, the md_id will also increment per sample.
SERIAL is a signed 32-Bit INT and could overflow in the far future.
Depending on the sampling interval and how many devices are deployed, we could hit the maximum integer value one day. We may want to change to a BIGSERIAL instead.
I believe that on the server side, we can even get rid of the md_id since we have ack_id, server_measurement_id - both not null which would serve as key. This would simplify things. The production server might need some updates on the DB since there the ack_id is currently allowed to be NULL for compatibility reasons.
At the moment, we use SERIAL IDs in the
measurement_data
relation:autopower/server/database_schema.sql
Line 49 in 956049c
Since we will constantly insert data into this table, the
md_id
will also increment per sample.SERIAL is a signed 32-Bit INT and could overflow in the far future.
Depending on the sampling interval and how many devices are deployed, we could hit the maximum integer value one day. We may want to change to a
BIGSERIAL
instead.As reference, see:
https://dba.stackexchange.com/questions/47591/should-i-be-concered-by-large-serial-values
The text was updated successfully, but these errors were encountered: