* set reasonable statement timeout
* backup with pitr. pg_dump is a headache on extremely busy servers.
Where do you put your pitr wal logs so that they don't take up extra
I/O ?
* get good i/o system for your box. start with 6 disk raid 10 and go
from there.
* spend some time reading about
On Mon, May 21, 2007 at 03:50:27PM -0400, Merlin Moncure wrote:
> I work on a system about like you describe400tps constant24/7.
> Major challenges are routine maintenance and locking. Autovacuum is
> your friend but you will need to schedule a full vaccum once in a
> while because of tps
I'm looking for a database+hardware solution which should be
able to handle up to 500 requests per second.
What proportion of reads and writes in those 500 tps ?
(If you have 450 selects and 50 inserts/update transactions, your
hardware requirements will be different than t
On 5/12/07, Tarhon-Onu Victor <[EMAIL PROTECTED]> wrote:
Hi guys,
I'm looking for a database+hardware solution which should be able
to handle up to 500 requests per second. The requests will consist in:
- single row updates in indexed tables (the WHERE clauses will use
t
On Tue, May 15, 2007 at 11:47:29AM +0100, Richard Huxton wrote:
> Tarhon-Onu Victor wrote:
> >On Mon, 14 May 2007, Richard Huxton wrote:
> >
> >>1. Is this one client making 500 requests, or 500 clients making one
> >>request per second?
> >
> >Up to 250 clients will make up to 500 requests pe
Tarhon-Onu Victor wrote:
On Mon, 14 May 2007, Richard Huxton wrote:
1. Is this one client making 500 requests, or 500 clients making one
request per second?
Up to 250 clients will make up to 500 requests per second.
Well, PG is pretty good at handling multiple clients. But if I'm
under
On Mon, 14 May 2007, Richard Huxton wrote:
1. Is this one client making 500 requests, or 500 clients making one request
per second?
Up to 250 clients will make up to 500 requests per second.
2. Do you expect the indexes at least to fit in RAM?
not entirely... or not all of
Tarhon-Onu Victor wrote:
Hi guys,
I'm looking for a database+hardware solution which should be able to
handle up to 500 requests per second.
Crucial questions:
1. Is this one client making 500 requests, or 500 clients making one
request per second?
2. Do you expect the indexes at
Hi guys,
I'm looking for a database+hardware solution which should be able
to handle up to 500 requests per second. The requests will consist in:
- single row updates in indexed tables (the WHERE clauses will use
the index(es), the updated column(s) will not be indexed);
- i
