[PERFORM] seqential vs random io

then I started wondering if it's not that simple, and my knowledge of stuff at the hardware level is, well, limited.   If it were your QA guy, what would you tell him? - DAP--David Parker    Tazz Networks   

[PERFORM] checkpoint segments

neral, and if I should strive to tune so that it never happens (if that's possible)?   Thanks. - DAP----------David Parker    Tazz Networks    (401) 709-5130   

Re: [PERFORM] batch inserts are "slow"

We ran into the need to use COPY, but our application is also in Java. We wrote a JNI bridge to a C++ routine that uses the libpq library to do the COPY. The coding is a little bit weird, but not too complicated - the biggest pain in the neck is probably getting it into your build system. Here's t

Re: [PERFORM] Performance problem with semi-large tables

You don't mention if you have run VACUUM or VACUUM ANALYZE lately. That's generally one of the first things that folks will suggest. If you have a lot of updates then VACUUM will clean up dead tuples; if you have a lot of inserts then VACUUM ANALYZE will update statistics so that the planner

Re: [PERFORM] time to stop tuning?

ce the need for client caching). Thanks. - DAP >-Original Message- >From: Rod Taylor [mailto:[EMAIL PROTECTED] >Sent: Friday, November 26, 2004 1:29 PM >To: David Parker >Cc: Postgresql Performance >Subject: Re: [PERFORM] time to stop tuning? > >On Fri, 2004-11-26 a

[PERFORM] time to stop tuning?

uning 3) more backend hardware But I would grateful to hear any tips/anecdotes/experiences that others might have from tuning similar applications. Thanks! - DAP ---------- David ParkerTazz Networks(401) 709-51

Re: [PERFORM] tablespace + RAM disk?

..I should stop talking and go read about tablespaces and memcached. I'd be interested to hear if anybody has tried this. And I will also check out memcached, too, of course. Thanks for the pointer. - DAP >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED

Re: [PERFORM] tablespace + RAM disk?

[EMAIL PROTECTED] >Cc: David Parker >Subject: Re: [PERFORM] tablespace + RAM disk? > >David, > >> We have a couple tables (holding information about network sessions, >> for >> instance) which don't need to persist beyond the life of the server, >> b

[PERFORM] tablespace + RAM disk?

t know if there are any special issues with defining a tablespace that way. Thanks. - DAP ------ David ParkerTazz Networks(401) 709-5130   ---(end of broadcast)---

Re: [PERFORM] query plan question

yze at the end of a long import - but this "mysterious" behavior was bugging me! Thanks. - DAP >-Original Message- >From: Matthew T. O'Connor [mailto:[EMAIL PROTECTED] >Sent: Wednesday, November 17, 2004 2:02 PM >To: David Parker >Cc: Tom Lane; Jeff; Russe

[PERFORM] sort_mem affect on inserts?

-- David ParkerTazz Networks(401) 709-5130   ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

Re: [PERFORM] query plan question

existing autovacuum threads would be greatly appreciated! Thanks. - DAP >-Original Message- >From: Tom Lane [mailto:[EMAIL PROTECTED] >Sent: Wednesday, November 17, 2004 10:46 AM >To: David Parker >Cc: Jeff; Russell Smith; [EMAIL PROTECTED] >Subject: Re: [PERFORM]

Re: [PERFORM] query plan question

isn't analyzing those tables. - DAP >-Original Message- >From: David Parker >Sent: Wednesday, November 17, 2004 9:44 AM >To: 'Jeff' >Cc: Russell Smith; [EMAIL PROTECTED] >Subject: RE: [PERFORM] query plan question > >I've got pg_autovacuum running o

Re: [PERFORM] query plan question

>From: Jeff [mailto:[EMAIL PROTECTED] >Sent: Wednesday, November 17, 2004 9:01 AM >To: David Parker >Cc: Russell Smith; [EMAIL PROTECTED] >Subject: Re: [PERFORM] query plan question > > >On Nov 17, 2004, at 7:32 AM, David Parker wrote: > >> Oh, I didn&#

Re: [PERFORM] query plan question

>If they are the same and PostgreSQL are the same, are the >intel machines Xeons? Yup, dual 3.06-GHz Intel Xeon Processors. I'm not sure off the top of my head what the sparcs are exactly. We're in the process of moving completely to intel, but we still have to support our app on sparc, and we a

Re: [PERFORM] query plan question

Oh, I didn't realize that analyze gave that much more info. I've got a lot to learn about this tuning stuff ;-) I've attached the output. I see from the new output where the slow query is taking its time (the nested loop at line 10), but I still have no idea why this plan is getting chosen T

[PERFORM] query plan question

at the 4th line of the plan, but I don't know why it would be different for the same schema, same dataset. What factors go into the planner's decision to choose a nested loop over a hash join? Should I be looking at adjusting my runtime configuration on the sparc box somehow? Thanks. - DAP -- David ParkerTazz Networks(401) 709-5130   ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster