Re: [PERFORM] rapid degradation after postmaster restart

2004-03-12 Thread Tom Lane
Joe Conway <[EMAIL PROTECTED]> writes: > The problem is this: the application runs an insert, that fires off a > trigger, that cascades into a fairly complex series of functions, that > do a bunch of calculations, inserts, updates, and deletes. Immediately > after a postmaster restart, the first

Re: [PERFORM] rapid degradation after postmaster restart

2004-03-12 Thread Marty Scholes
Six days ago I installed Pg 7.4.1 on Sparc Solaris 8 also. I am hopeful that we as well can migrate a bunch of our apps from Oracle. After doing some informal benchmarks and performance testing for the past week I am becoming more and more impressed with what I see. I have seen similar results

[PERFORM] rapid degradation after postmaster restart

2004-03-12 Thread Joe Conway
I'm trying to troubleshoot a performance issue on an application ported from Oracle to postgres. Now, I know the best way to get help is to post the schema, explain analyze output, etc, etc -- unfortunately I can't do that at the moment. However, maybe someone can point me in the right directio

Re: [PERFORM] Scaling further up

2004-03-12 Thread Robert Treat
On Mon, 2004-03-08 at 11:40, William Yu wrote: > Anjan Dave wrote: > > Great response, Thanks. > > > > Regarding 12GB memory and 13G db, and almost no I/O, one thing I don't > > understand is that even though the OS caches most of the memory and PG > > can use it if it needs it, why would the syst

Re: [PERFORM] pg_xlog on same drive as OS

2004-03-12 Thread Christopher Browne
In the last exciting episode, [EMAIL PROTECTED] wrote: > greetings! > on a dedicated pgsql server is putting pg_xlog > in drive as OS almost equivalent to putting on a seperate > drive? > > in both case the actual data files are in a seperate > drive. Well, if the OS drive is relatively inactive,

Re: [PERFORM] pg_xlog on same drive as OS

2004-03-12 Thread Josh Berkus
Mallah, > on a dedicated pgsql server is putting pg_xlog > in drive as OS almost equivalent to putting on a seperate > drive? Yes. If I have limited drives, this is what I do. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)-

[PERFORM] pg_xlog on same drive as OS

2004-03-12 Thread mallah
greetings! on a dedicated pgsql server is putting pg_xlog in drive as OS almost equivalent to putting on a seperate drive? in both case the actual data files are in a seperate drive. regds mallah ---(end of broadcast)--- TIP 9: the planner will ig

Re: [PERFORM] severe performance issue with planner

2004-03-12 Thread Greg Stark
Sorry, I forgot a key clause there: Greg Stark <[EMAIL PROTECTED]> writes: > select w8.wid, >w8.variant, >w8.num_variants, >sum_text(w8.unicode) as unicodes, >sum_text(w8.pinyin) as pinyins > from ( > select wid,variant, > from words >

Re: [PERFORM] severe performance issue with planner

2004-03-12 Thread Greg Stark
The other posts about using explicit joins and using stored procedures are both good points. But I have a few other comments to make: "Eric Brown" <[EMAIL PROTECTED]> writes: > WHERE > w0.wid > 0 AND > w0.pinyin = 'zheng4' AND > w0.def_exists = 't' AND > w0.sequence = 0 AND >

Re: [PERFORM] optimizing large query with IN (...)

2004-03-12 Thread Josh Berkus
Marcus, > The problem, as I understand it, is that 7.4 introduced massive > improvements in handling moderately large in() clauses, as long as they > can fit in sort_mem, and are provided by a subselect. Also, this problem may be fixed in 7.5, when it comes out. It's a known issue. -- Josh Be