Re: [PERFORM] Solaris Performance (Again)

2003-12-10 Thread Jeff
On Wed, 10 Dec 2003 18:56:38 +1300 Mark Kirkwood <[EMAIL PROTECTED]> wrote: > The major performance killer appeared to be mounting the filesystem > with the logging option. The next most significant seemed to be the > choice of sync_method for Pg - the default (open_datasync), which we > initially

Re: [PERFORM] TRUNCATE veeeery slow compared to DELETE in 7.4

2003-12-10 Thread Josh Berkus
Hartmut, > DELETE: > 1) 0.03u 0.04s 0:02.46 2.8% (already empty) > 2) 0.05u 0.06s 0:01.19 9.2% (already empty) > > TRUNCATE: > 1) 0.10u 0.06s 6:58.66 0.0% (already empty, compile runnig simult.) > 2) 0.10u 0.02s 2:51.71 0.0% (already empty) How about some times for a full table? Incidentally, I

Re: [PERFORM] Solaris Performance (Again)

2003-12-10 Thread Neil Conway
Mark Kirkwood <[EMAIL PROTECTED]> writes: > Note : The Pgbench runs were conducted using -s 10 and -t 1000 -c > 1->64, 2 - 3 runs of each setup were performed (averaged figures > shown). FYI, the pgbench docs state: NOTE: scaling factor should be at least as large as the largest numbe

[PERFORM]

2003-12-10 Thread nbarraza
I have some problems on performance using postgresql v. 7.3.2 running on Linux RedHat 9. An update involving several rows (about 50) on a table having 280 tuples takes in the order of 6 minutes. It is more than it takes on other plataforms (SqlServer, FOX). I think that there´s something

Re: [PERFORM] TRUNCATE veeeery slow compared to DELETE in 7.4

2003-12-10 Thread Tom Lane
Josh Berkus <[EMAIL PROTECTED]> writes: > Incidentally, I believe that TRUNCATE has always been slightly slower than > DROP TABLE. Well, it would be: it has to delete the original files and then create new ones. I imagine the time to create new, empty indexes is the bulk of the time Hartmut is m

Re: [PERFORM]

2003-12-10 Thread Stephan Szabo
On Wed, 10 Dec 2003 [EMAIL PROTECTED] wrote: > I have some problems on performance using postgresql v. 7.3.2 running on > Linux RedHat 9. An update involving several rows (about 50) on a > table having 280 tuples takes in the order of 6 minutes. It is more > than it takes on other platafo

[PERFORM] Performance problems with a higher number of clients

2003-12-10 Thread Alfranio Correia Junior
Hello, I am facing a problem trying to put 500 concurrent users accessing a postgresql instance. Basically, the machine begins to do a lot i/o... swap area increases more and more... The vmstat began with 9200 (swpd) and after 20 minutes it was like that: VMSTAT: procs me

Re: [PERFORM] Solaris Performance (Again)

2003-12-10 Thread Mark Kirkwood
Good point - It is Pg 7.4beta1 , compiled with CFLAGS += -O2 -funroll-loops -fexpensive-optimizations Jeff wrote: What version of PG? If it is before 7.4 PG compiles with _NO_ optimization by default and was a huge part of the slowness of PG on solaris. ---(end o

Re: [PERFORM] Solaris Performance (Again)

2003-12-10 Thread Mark Kirkwood
yes - originally I was going to stop at 8 clients, but once the bit was between the teethIf I get another box to myself I will try -s 50 or 100 and see what that shows up. cheers Mark Neil Conway wrote: FYI, the pgbench docs state: NOTE: scaling factor should be at least as large as

Re: [PERFORM] Performance problems with a higher number of clients

2003-12-10 Thread Shridhar Daithankar
Alfranio Correia Junior wrote: Postgresql configuration: effective_cache_size = 35000 shared_buffers = 5000 random_page_cost = 2 cpu_index_tuple_cost = 0.0005 sort_mem = 10240 Lower sort mem to say 2000-3000, up shared buffers to 10K and up effective cache size to around 65K. That should make it