... | ... | @@ -153,9 +153,9 @@ The RPS for all daemons for an interval could fetched in single select: |
|
|
So when new values are going to be inserted first we would look for some old record.
|
|
|
If it is found then it would be used for new data. Otherwise insert would be used.
|
|
|
This way we do not have to play with looking for old records and deleting them and
|
|
|
then waiting for vacuum in Postgresql for reclaiming storage.
|
|
|
then waiting for vacuum in PostgreSQL for reclaiming storage.
|
|
|
|
|
|
Response: It is simpler and possibly faster to "add to the end" and age off "from the beginning". This lets the table operate like a FIFO queue and the logic is straight forward. Trying to reuse existing but obsolete records would be more complicated and possibly slower. It would require more trips to the database or a stored procedure. I don't think we are looking at a volume of records that waiting for Postgresql to reclaim space is going to be an issue. If it is then it isn't tuned properly. I believe we should follow the KISS principle here, until or unless it proves to be insufficient. Either way, the implementation could be changed readily enough.
|
|
|
Response: It is simpler and possibly faster to "add to the end" and age off "from the beginning". This lets the table operate like a FIFO queue and the logic is straight forward. Trying to reuse existing but obsolete records would be more complicated and possibly slower. It would require more trips to the database or a stored procedure. I don't think we are looking at a volume of records that waiting for PostgreSQL to reclaim space is going to be an issue. If it is then it isn't tuned properly. I believe we should follow the KISS principle here, until or unless it proves to be insufficient. Either way, the implementation could be changed readily enough.
|
|
|
|
|
|
## Authors (please add yourself when you contribute):
|
|
|
|
... | ... | |