Re: [PERFORM] RAID or manual split?

2004-02-20 Thread Rod Taylor
> There are frequent (100-1000/day) queries of both the > inventory and summary tables using the primary key -- always using the > index and returning < 10 rows. For this query frequency I don't think splitting the drives will do much -- you just need more IO. Look at optimizing the query themselv

[PERFORM] JOIN order, 15K, 15K, 7MM rows

2004-02-20 Thread Andrew Lazarus
All three tables have the same integer key, and it's indexed.   I parenthesized the joins to do the two small tables first.   I'm running and INSERT INTO ... SELECT query with this join (one record added per record in join), 4 hours down and all I have to show for it is 100 recycled transact

Re: [PERFORM] General performance questions about postgres on Apple

2004-02-20 Thread Sean Shanny
scott.marlowe wrote: On Fri, 20 Feb 2004, Sean Shanny wrote: max_connections = 100 # - Memory - shared_buffers = 16000 # min 16, at least max_connections*2, 8KB each sort_mem = 256000 # min 64, size in KB You might wanna drop sort_mem somewhat and just set it d

Re: [PERFORM] [ADMIN] Index called with Union but not with OR clause

2004-02-20 Thread Bruno Wolff III
This discussion really belongs on the performance list and I am copying that list with mail-followup-to set. On Fri, Feb 20, 2004 at 12:26:22 +0530, V Chitra <[EMAIL PROTECTED]> wrote: > Hi All, > > I have a select statement > > select * from v_func_actual_costs > where parent_project='10478'

[PERFORM] General performance questions about postgres on Apple hardware...

2004-02-20 Thread Sean Shanny
To all, This is a 2 question email. First is asking about general tuning of the Apple hardware/postgres combination. The second is whether is is possible to speed up a particular query. PART 1 Hardware: Apple G5 dual 2.0 with 8GB memory attached via dual fibre channel to a fully loaded 3.5

Re: [PERFORM] cacheable stored functions?

2004-02-20 Thread Bill Moran
Richard Huxton wrote: On Friday 20 February 2004 15:35, Bill Moran wrote: I'm converting a SQL application to PostgreSQL. The majority of the logic in this application is in the stored functions in the database. Somewhere, I saw a reference to "WITH (iscachable)" for stored functions, looking aga

Re: [PERFORM] cacheable stored functions?

2004-02-20 Thread Richard Huxton
On Friday 20 February 2004 15:35, Bill Moran wrote: > I'm converting a SQL application to PostgreSQL. The majority of the logic > in this application is in the stored functions in the database. > > Somewhere, I saw a reference to "WITH (iscachable)" for stored functions, > looking again, I'm unabl

Re: [PERFORM] cacheable stored functions?

2004-02-20 Thread Tomasz Myrta
Dnia 2004-02-20 16:35, Użytkownik Bill Moran napisał: Can anyone say whether this is a supported feature in plpgsql, and is safe to use? Is it simply undocumented, or am I just looking in the wrong place? "iscachable" is only for backward compatibility - it's changed now to "IMMUTABLE" You can r

Re: [PERFORM] cacheable stored functions?

2004-02-20 Thread Stephan Szabo
On Fri, 20 Feb 2004, Bill Moran wrote: > I'm converting a SQL application to PostgreSQL. The majority of the logic > in this application is in the stored functions in the database. > > Somewhere, I saw a reference to "WITH (iscachable)" for stored functions, > looking again, I'm unable to find an

[PERFORM] cacheable stored functions?

2004-02-20 Thread Bill Moran
I'm converting a SQL application to PostgreSQL. The majority of the logic in this application is in the stored functions in the database. Somewhere, I saw a reference to "WITH (iscachable)" for stored functions, looking again, I'm unable to find any reference to this directive. I have a single fu

Re: [PERFORM] Slow response of PostgreSQL

2004-02-20 Thread Neil Conway
Shridhar Daithankar <[EMAIL PROTECTED]> writes: > Right now, it is hotly debated on HACKERS about adding a NOWAIT > clause to SELECT FOR UPDATE. If you think your application > deployment is away for months and can try CVS head, you can expect > some action on it in coming few days. You can also t

Re: [PERFORM] Slow in morning hours

2004-02-20 Thread Bill Moran
[EMAIL PROTECTED] wrote: Hi All, I am using Linux 7.2 and postgresql 7.2. Our Office hours are over at 6pm but we use to keep our server running 24 hours a day. On the second day morning, Our PGSQL Server becomes very slow. After continuous usage of one hour, It gradually starts responding f

Re: [PERFORM] Slow in morning hours

2004-02-20 Thread Andrew Sullivan
On Fri, Feb 20, 2004 at 02:46:15PM +0530, [EMAIL PROTECTED] wrote: > > After continuous usage of one hour, It gradually starts responding > faster ! This has become every day routine ! > > do u have any idea related to this Is there any other reason that I > need to check up? What's runni

[PERFORM] Slow in morning hours

2004-02-20 Thread vathakar
Hi All, I am using Linux 7.2 and postgresql 7.2. Our Office hours are over at 6pm but we use to keep our server running 24 hours a day. On the second day morning, Our PGSQL Server becomes very slow. After continuous usage of one hour, It gradually starts responding faster ! This has become e