Re: Storing sensor data - Mailing list pgsql-performance

From Ivan Voras
Subject Re: Storing sensor data
Date
Msg-id 9bbcef730905280758p4400d600k8e5e4345cd07100@mail.gmail.com
Whole thread Raw
In response to Re: Storing sensor data  (Nikolas Everett <nik9000@gmail.com>)
List pgsql-performance
2009/5/28 Nikolas Everett <nik9000@gmail.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.

pgsql-performance by date:

Previous
From: Ivan Voras
Date:
Subject: Re: Storing sensor data
Next
From: Kenneth Marshall
Date:
Subject: Re: Storing sensor data