Re: Restricting Postgres

From: "Matt Clark" <matt(at)ymogen(dot)net>
To: "'Martin Foster'" <martin(at)ethereal-realms(dot)org>
Cc: "'Matthew Nuzum'" <newz(at)bearfruit(dot)org>, "'PostgreSQL Performance'" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Restricting Postgres
Date: 2004-11-04 18:20:18
Message-ID: 003301c4c29a$f052d910$8300a8c0@solent
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

> Correct the 75% of all hits are on a script that can take
> anywhere from
> a few seconds to a half an hour to complete. The script
> essentially
> auto-flushes to the browser so they get new information as it arrives
> creating the illusion of on demand generation.

This is more like a streaming data server, which is a very different beast
from a webserver, and probably better suited to the job. Usually either
multithreaded or single-process using select() (just like Squid). You could
probably build one pretty easily. Using a 30MB Apache process to serve one
client for half an hour seems like a hell of a waste of RAM.

> A squid proxy would probably cause severe problems when
> dealing with a
> script that does not complete output for a variable rate of time.

No, it's fine, squid gives it to the client as it gets it, but can receive
from the server faster.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message William Yu 2004-11-04 19:33:26 Re: PostgreSQL on Linux PC vs MacOS X
Previous Message Martin Foster 2004-11-04 18:04:00 Re: Restricting Postgres

Browse pgsql-performance by date

  From Date Subject
Next Message Simon Riggs 2004-11-04 19:03:47 Re: Anything to be gained from a 'Postgres Filesystem'?
Previous Message Martin Foster 2004-11-04 18:04:00 Re: Restricting Postgres