[PERFORM] Avoiding cartesian product

2006-01-03 Thread Virag Saksena
I have a table which stores cumulative valuesI would like to display/chart the deltas between successive data collections   If my primary key only increments by 1, I could write a simple query   select b.gc_minor - a.gc_minor, b.gc_major - a.gc_major  from jam_trace_sys a, jam_trace_sys b wh

Re: [PERFORM] improving write performance for logging application

2006-01-03 Thread dlang
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

Re: [PERFORM] improving write performance for logging application

2006-01-03 Thread Steinar H. Gunderson
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

Re: [PERFORM] improving write performance for logging application

2006-01-03 Thread Tom Lane
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'

[PERFORM] improving write performance for logging application

2006-01-03 Thread Steve Eckmann
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

Re: [PERFORM] Materialize Subplan and push into inner index conditions

2006-01-03 Thread Tom Lane
Jens-Wolfhard Schicke <[EMAIL PROTECTED]> writes: > Is it possible to have the planner consider the second plan instead of the > first? At the moment, only if you get rid of the inheritance. The planner's not very smart at all when faced with joining inheritance trees. r

[PERFORM] Materialize Subplan and push into inner index conditions

2006-01-03 Thread Jens-Wolfhard Schicke
Is it possible to have the planner consider the second plan instead of the first? admpostgres4=> explain analyze select * from users where id in (select user_id from user2user_group where user_group_id = 769694); QUERY PLAN --