Re: [PERFORM] Hardware vs Software Raid

2008-06-26 Thread Peter T. Breuer
Also sprach Merlin Moncure: write back: raid controller can lie to host o/s. when o/s asks This is not what the linux software raid controller does, then. It does not queue requests internally at all, nor ack requests that have not already been acked by the components (modulo the fact that one

Re: [PERFORM] Hardware vs Software RAID

2008-06-25 Thread Peter T. Breuer
Also sprach Matthew Wakeling: Has anyone done some benchmarks between hardware RAID vs Linux MD software RAID? ... The upshot is I don't really see a difference in performance. The main difference is that you can get hardware RAID with battery-backed-up cache, which means small writes

Re: [PERFORM] general PG network slowness (possible cure) (repost)

2007-05-26 Thread Peter T. Breuer
Also sprach Tom Lane: Peter T. Breuer [EMAIL PROTECTED] writes: But can I prepare a DECLARE x BINARY CURSOR FOR SELECT ... statement? The manual seems to say no. No, you just prepare the SELECT. At the protocol level, DECLARE CURSOR is a tad useless. You can still fetch the data

[PERFORM] general PG network slowness (possible cure) (repost)

2007-05-25 Thread Peter T. Breuer
I set up pg to replace a plain gdbm database for my application. But even running to the same machine, via a unix socket * the pg database ran 100 times slower Across the net it was * about 500 to 1000 times slower than local gdbm with no cpu use to speak of. I'd heard that networked

Re: [PERFORM] general PG network slowness (possible cure) (repost)

2007-05-25 Thread Peter T. Breuer
Also sprach Kenneth Marshall: Surprise, ... I got a speed up of hundreds of times. The same application that crawled under my original rgdbm implementation and under PG now maxed out the network bandwidth at close to a full 10Mb/s and 1200 pkts/s, at 10% CPU on my 700MHz client, and a

Re: [PERFORM] general PG network slowness (possible cure) (repost)

2007-05-25 Thread Peter T. Breuer
Also sprach Richard Huxton: [Charset ISO-8859-1 unsupported, filtering to ASCII...] Peter T. Breuer wrote: I set up pg to replace a plain gdbm database for my application. But even running to the same machine, via a unix socket * the pg database ran 100 times slower For what

Re: [PERFORM] general PG network slowness (possible cure) (repost)

2007-05-25 Thread Peter T. Breuer
Also sprach Richard Huxton: I'm not sure you really want a full RDBMS. If you only have a single connection and are making basic key-lookup queries then 90% of PostgreSQL's code is just getting in your way. Sounds to me like gdbm Yep - I could happily tell it not to try and compile a

Re: [PERFORM] general PG network slowness (possible cure) (repost)

2007-05-25 Thread Peter T. Breuer
Also sprach Alvaro Herrera: I really think it would be worthwhile getting some developer to tell me where the network send is done in PG. See src/backend/libpq/pqcomm.c (particularly internal_flush()). Yes. Thanks. That looks like it. It calls secure_write continually until the buffer is

Re: [PERFORM] general PG network slowness (possible cure) (repost)

2007-05-25 Thread Peter T. Breuer
Also sprach Tom Lane: Peter T. Breuer [EMAIL PROTECTED] writes: And definitely all those could be grouped if there are several to do. Except that in the situation you're describing, there's only a hundred or two bytes of response to each query, which means that only one send() will occur

Re: [PERFORM] general PG network slowness (possible cure) (repost)

2007-05-25 Thread Peter T. Breuer
Also sprach Kenneth Marshall: improvement from coalescing the packets. Good luck in your investigations. While I am recompiling stuff, just some stats. Typical network traffic analysis during the PG runs: Total Packets Processed 493,499 Unicast 100.0% 493,417 Broadcast

Re: [PERFORM] general PG network slowness (possible cure) (repost)

2007-05-25 Thread Peter T. Breuer
Also sprach Richard Huxton: scheme each time, for example! (how that?). I could presumably also help it by preloading the commands I will run and sending over the params only with a do a no. 17 now!. PREPARE/EXECUTE (or the equivalent libpq functions). Yes, thank you. It seems to speed