| From: | Marsh Ray <marsh5143(at)gmail(dot)com> |
|---|---|
| To: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Commit visibility guarantees |
| Date: | 2009-05-18 22:18:06 |
| Message-ID: | 2afbdd3f0905181518x7d769723rde49a3cf994b28c@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, May 18, 2009 at 4:53 PM, Ben Chobot <bench(at)silentmedia(dot)com> wrote:
> On Mon, 18 May 2009, Marsh Ray wrote:
>> Hello Everyone,
>> I'm looking at an easy real-time application using PostgreSQL.
> As I understand real-time applications, PostgreSQL is inherintly unsuited
> for the task. There is absolutely no timing constraints on your queries, and
> "large" sets of working data can sometimes spill to disk, which incurs the
> obvious - but not always consistent - performance hit.
Definitely true, but I don't think it's really the issue here. The app
does have a hard real-time deadline, but the deadline is generally
quite "easy" for such a system. Like any web app, there will be a hard
deadline to meet before the browser times out, though the timeout
value 60 or more seconds.
There is a near-instantaneous context switch from the 'update' process
to the 'select' process, and I am wondering if some behaviors change
with that tight scheduling.
- Marsh
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sam Mason | 2009-05-18 22:24:13 | Re: Commit visibility guarantees |
| Previous Message | Sam Mason | 2009-05-18 22:14:02 | Re: Commit visibility guarantees |