"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 on
"Also sprach Greg Smith:"
> On Wed, 25 Jun 2008, Peter T. Breuer wrote:
>
> > You can put the log/bitmap wherever you want in software raid, including
> > on a battery-backed local ram disk if you feel so inclined. So there is
> > no intrinsic advantage to be
"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
Translaterating ...
"Also sprach Fabio Arias:"
> Hola amigos, les escribo por que necesito conocer si PostgreSQL es lo
> suficientemente robusto para manejar una plataforma transaccional de 2000 tx
> per second. necesito conocer la manera de separar mi operacion transaccional
> de la aquella que e
"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
"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 see
"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
Broadca
"Also sprach Tom Lane:"
> > It may still be useful. The kernel won't necessarily send data as you
> > push it down to the network protocols and driver. The driver may decide
> > to wait for more data to accumulate,
>
> No, because we set TCP_NODELAY. Once we've flushed a message to the
That just
"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
"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 buff
"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 sp
"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
> >
> >*
"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,
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
14 matches
Mail list logo
