Re: [PERFORM] Slow response of PostgreSQL

2004-06-03 Thread Stephan Szabo
On Tue, 17 Feb 2004, Saleem Burhani Baloch wrote: select count(*), sum(vl_ex_stax) , sum(qty) , unit from inv_detail group by unit; on both databases. PostgreSQL Machine ** P-III 600Mhz (Dell Precision 220) 256 MB Ram (RD Ram) 40 GB Baracuda Ext2 File System. RedHat 7.2

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 try

Re: [PERFORM] Slow response of PostgreSQL

2004-02-19 Thread Saleem Burhani Baloch
Hi, Thanks every one for helping me. I have upgraded to 7.4.1 on redhat 8 ( rh 9 require a lot of lib's) and set the configuration sent by Chris. Now the query results in 6.3 sec waooo. I m thinking that why the 7.1 process aggregate slowly. Anyway. I still have to go for 2 sec result and now

Re: [PERFORM] Slow response of PostgreSQL

2004-02-19 Thread Shridhar Daithankar
On Thursday 19 February 2004 14:31, Saleem Burhani Baloch wrote: Hi, Thanks every one for helping me. I have upgraded to 7.4.1 on redhat 8 ( rh 9 require a lot of lib's) and set the configuration sent by Chris. Now the query results in 6.3 sec waooo. I m thinking that why the 7.1 process

Re: [PERFORM] Slow response of PostgreSQL

2004-02-19 Thread Christopher Kings-Lynne
Thanks every one for helping me. I have upgraded to 7.4.1 on redhat 8 ( rh 9 require a lot of lib's) and set the configuration sent by Chris. Now the query results in 6.3 sec waooo. I m thinking that why the 7.1 process aggregate slowly. Anyway. I'm glad we could help you Saleem :) We knew

Re: [PERFORM] Slow response of PostgreSQL

2004-02-19 Thread Hannu Krosing
Saleem Burhani Baloch kirjutas N, 19.02.2004 kell 11:01: Hi, Thanks every one for helping me. I have upgraded to 7.4.1 on redhat 8 ( rh 9 require a lot of lib's) and set the configuration sent by Chris. Now the query results in 6.3 sec waooo. I m thinking that why the 7.1 process

Re: [PERFORM] Slow response of PostgreSQL

2004-02-17 Thread Bill Moran
Christopher Kings-Lynne wrote: 1- How can I lock a single record so that other users can only read it. ?? You cannot do that in PostgreSQL. How about SELECT ... FOR UPDATE? -- Bill Moran Potential Technologies http://www.potentialtech.com ---(end of

Re: [PERFORM] Slow response of PostgreSQL

2004-02-17 Thread Tom Lane
Saleem Burhani Baloch [EMAIL PROTECTED] writes: I have a question why MS-SQL with 256 MB RAM gives result in 2 sec ?? If I have low memory Postgres should give result in 10 sec as compared to MS-SQL. Are you still running 7.1? regards, tom lane

Re: [PERFORM] Slow response of PostgreSQL

2004-02-17 Thread scott.marlowe
Easy two step procedure for speeding this up: 1: Upgrade to 7.4.1 2: Read this: http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html ---(end of broadcast)--- TIP 6: Have you searched our list archives?

Re: [PERFORM] Slow response of PostgreSQL

2004-02-17 Thread Christopher Kings-Lynne
1- How can I lock a single record so that other users can only read it. ?? You cannot do that in PostgreSQL. How about SELECT ... FOR UPDATE? No, because users cannot read the locked row in that case. Chris ---(end of broadcast)--- TIP 7:

Re: [PERFORM] Slow response of PostgreSQL

2004-02-17 Thread scott.marlowe
On Wed, 18 Feb 2004, Christopher Kings-Lynne wrote: 1- How can I lock a single record so that other users can only read it. ?? You cannot do that in PostgreSQL. How about SELECT ... FOR UPDATE? No, because users cannot read the locked row in that case. I just tested it

Re: [PERFORM] Slow response of PostgreSQL

2004-02-17 Thread Bill Moran
scott.marlowe wrote: On Wed, 18 Feb 2004, Christopher Kings-Lynne wrote: 1- How can I lock a single record so that other users can only read it. ?? You cannot do that in PostgreSQL. How about SELECT ... FOR UPDATE? No, because users cannot read the locked row in that case. I just tested it

Re: [PERFORM] Slow response of PostgreSQL

2004-02-17 Thread Christopher Kings-Lynne
How about SELECT ... FOR UPDATE? No, because users cannot read the locked row in that case. I just tested it (within transactions) and it appeared that I could still view the rows selected for update. Ah, true. My mistake. OK, well you can do it in postgres then... Chris

Re: [PERFORM] Slow response of PostgreSQL

2004-02-16 Thread Tom Lane
Saleem Burhani Baloch [EMAIL PROTECTED] writes: PostgreSQL 7.1.3-2 Aside from the config issues Chris mentioned, I'd recommend trying a somewhat less obsolete version of Postgres. I believe the poor performance with grouped aggregates should be fixed in 7.4 and later. (Red Hat 7.2 is a bit