From: | Ivan Voras <ivoras(at)freebsd(dot)org> |
---|---|
To: | Nikolas Everett <nik9000(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Storing sensor data |
Date: | 2009-05-28 14:58:12 |
Message-ID: | 9bbcef730905280758p4400d600k8e5e4345cd07100@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
2009/5/28 Nikolas Everett <nik9000(at)gmail(dot)com>:
> Option 1 is about somewhere between 2 and 3 times more work for the database
> than option 2.
Yes, for writes.
> Do you need every sensor update to hit the database? In a situation like
We can't miss an update - they can be delayed but they all need to be recorded.
> this I'd be tempted to keep the current values in the application itself and
> then sweep them all into the database periodically. If some of the sensor
> updates should hit the database faster, you could push those in as you get
> them rather than wait for your sweeper. This setup has the advantage that
> you can scale up the number of sensors and the frequency the sensors report
> without having to scale up the disks. You can also do the sweeping all in
> one transaction or even in one batch update.
It would be nice, but then we need to invest more effort in making the
front-end buffering resilient.
From | Date | Subject | |
---|---|---|---|
Next Message | Kenneth Marshall | 2009-05-28 15:01:02 | Re: Storing sensor data |
Previous Message | Ivan Voras | 2009-05-28 14:55:34 | Re: Storing sensor data |