Kelly Burkhart wrote:
On 1/4/06, Steve Eckmann
<[EMAIL PROTECTED]>
wrote:
Thanks,
Steinar. I don't think we would really run with fsync off, but
I need to document the performance tradeoffs. You're right that my
explanation was confusing; probably because I'm confused about how to
use COPY
Tom Lane wrote:
Steve Eckmann <[EMAIL PROTECTED]> writes:
<>Thanks for the suggestion, Tom. Yes, I
think I could do that. But I
thought what I was doing now was effectively the same, because the
PostgreSQL 8.0.0 Documentation says (section 27.3.1): "It is allowed to
include multi
On 1/4/06, Steve Eckmann <[EMAIL PROTECTED]> wrote:
Thanks, Steinar. I don't think we would really run with fsync off, but
I need to document the performance tradeoffs. You're right that my
explanation was confusing; probably because I'm confused about how to
use COPY! I could batch multiple INSERT
Steve Eckmann <[EMAIL PROTECTED]> writes:
> Thanks for the suggestion, Tom. Yes, I think I could do that. But I
> thought what I was doing now was effectively the same, because the
> PostgreSQL 8.0.0 Documentation says (section 27.3.1): "It is allowed to
> include multiple SQL commands (separate
Ian Westmacott wrote:
We have a similar application thats doing upwards of 2B inserts
per day. We have spent a lot of time optimizing this, and found the
following to be most beneficial:
1) use COPY (BINARY if possible)
2) don't use triggers or foreign keys
3) put WAL and tables on differen
dlang wrote:
On Tue, 3 Jan 2006, Tom Lane wrote:
Steve Eckmann <[EMAIL PROTECTED]> writes:
We also found that we could improve MySQL performance significantly
using MySQL's "INSERT" command extension allowing multiple value-list
tuples in a single command; the rat
Steinar H. Gunderson wrote:
On Tue, Jan 03, 2006 at 04:44:28PM -0700, Steve Eckmann wrote:
Are there general guidelines for tuning the PostgreSQL server for this kind
of application? The suggestions I've found include disabling fsync (done),
Are you sure you really want
Tom Lane wrote:
Steve Eckmann <[EMAIL PROTECTED]> writes:
We also found that we could improve MySQL performance significantly
using MySQL's "INSERT" command extension allowing multiple value-list
tuples in a single command; the rate for MyISAM tables improved to
about 2600 objects/
We have a similar application thats doing upwards of 2B inserts
per day. We have spent a lot of time optimizing this, and found the
following to be most beneficial:
1) use COPY (BINARY if possible)
2) don't use triggers or foreign keys
3) put WAL and tables on different spindles (channels if p
On Tue, 3 Jan 2006, Tom Lane wrote:
> Steve Eckmann <[EMAIL PROTECTED]> writes:
> > We also found that we could improve MySQL performance significantly
> > using MySQL's "INSERT" command extension allowing multiple value-list
> > tuples in a single command; the rate for MyISAM tables improved to
On Tue, Jan 03, 2006 at 04:44:28PM -0700, Steve Eckmann wrote:
> Are there general guidelines for tuning the PostgreSQL server for this kind
> of application? The suggestions I've found include disabling fsync (done),
Are you sure you really want this? The results could be catastrophic in case
of
Steve Eckmann <[EMAIL PROTECTED]> writes:
> We also found that we could improve MySQL performance significantly
> using MySQL's "INSERT" command extension allowing multiple value-list
> tuples in a single command; the rate for MyISAM tables improved to
> about 2600 objects/second. PostgreSQL doesn'
I have questions about how to improve the write performance of PostgreSQL for
logging data from a real-time simulation. We found that MySQL 4.1.3 could log
about 1480 objects/second using MyISAM tables or about 1225 objects/second
using InnoDB tables, but PostgreSQL 8.0.3 could log only about 5
13 matches
Mail list logo
