> I think you are right that the difference between 7.1 and 7.2 may have
> more to do with the change in VACUUM strategy than anything else.  Could
> you retry the test after changing all the "vacuum" commands in pgbench.c
> to "vacuum full"?

Might there also be a difference in chosen query plans ?
Wasn't 7.1 more willing to choose an index over seq scan,
even though the scan would be faster in the single user case ?
Or was that change after 7.0 ?

The seq scan would be slower that the index in the case of 
many concurrent accesses.

Andreas

Wed, 19 Dec 2001 11:38:28 +0100
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: 7.2 is slow? 
I haven't tested with the new 7.2 betas, but here are some results from
7.1.

We have a developement computer, IBM x series 250, with 4 processors
(PIII Xeon 750Mhz), 1 Gb memory and  2SCSI disks (u160).

The software is writing new rows to a table, and after this it reads the
id from that row. There are currently about 50 connections doing the
same thing.

When I run this test with the Redhat 7.1, with SMP kernel, I noticed, that
the
processors are more than 90% idle. Disks utilisation is not the
bottleneck either, since there is very low disk usage. Some data is
written to disks every 4-5 seconds. Fsync is turned of. In transactions,
this means about 200 inserted rows per second. The software that is used
to give the feed, is capable of several thousand rows per second.

Okey, so I tried this also with the same computer, but using the not SMP
supported kernel. So only with one processor. The result was about 600
rows per second. The configuration file was unchanged. Now, the
processor is about 100% utilized.

I didn't find any parameters that should help in this, but if you have a
version of 7.2 that you would like to get information about, let me
know, so I'll test.

Jussi

Zeugswetter Andreas SB SD wrote:

> > I think you are right that the difference between 7.1 and 7.2 may have
> > more to do with the change in VACUUM strategy than anything else.  Could
> > you retry the test after changing all the "vacuum" commands in pgbench.c
> > to "vacuum full"?
>
> Might there also be a difference in chosen query plans ?
> Wasn't 7.1 more willing to choose an index over seq scan,
> even though the scan would be faster in the single user case ?
> Or was that change after 7.0 ?
>
> The seq scan would be slower that the index in the case of
> many concurrent accesses.
>
> Andreas
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

--
Jussi Mikkola                    Project Manager
Bonware Oy                       gsm +358 40 830 7561
Tekniikantie 12                  tel +358 9 2517 5570
02150 Espoo                      fax +358 9 2517 5571
Finland                          www.bonware.com




I haven't tested with the new 7.2 betas, but here are some results from
7.1.
We have a developement computer, IBM x series 250, with 4 processors
(PIII Xeon 750Mhz), 1 Gb memory and  2SCSI disks (u160).
The software is writing new rows to a table, and after this it reads
the
id from that row. There are currently about 50 connections doing the
same thing.
When I run this test with the Redhat 7.1, with SMP kernel, I noticed,
that the
processors are more than 90% idle. Disks utilisation is not the
bottleneck either, since there is very low disk usage. Some data is
written to disks every 4-5 seconds. Fsync is turned of. In transactions,
this means about 200 inserted rows per second. The software that is
used
to give the feed, is capable of several thousand rows per second.
Okey, so I tried this also with the same computer, but using the not
SMP
supported kernel. So only with one processor. The result was about
600
rows per second. The configuration file was unchanged. Now, the
processor is about 100% utilized.
I didn't find any parameters that should help in this, but if you have
a
version of 7.2 that you would like to get information about, let me
know, so I'll test.
Jussi
Zeugswetter Andreas SB SD wrote:
> I think you are right that the difference between
7.1 and 7.2 may have
> more to do with the change in VACUUM strategy than anything else. 
Could
> you retry the test after changing all the "vacuum" commands in pgbench.c
> to "vacuum full"?
Might there also be a difference in chosen query plans ?
Wasn't 7.1 more willing to choose an index over seq scan,
even though the scan would be faster in the single user case ?
Or was that change after 7.0 ?
The seq scan would be slower that the index in the case of
many concurrent accesses.
Andreas
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
-- 
Jussi Mikkola                    Project Manager
Bonware Oy                       gsm +358 40 830 7561
Tekniikantie 12                  tel +358 9 2517 5570
02150 Espoo                      fax +358 9 2517 5571 
Finland                          www.bonware.com
Wed, 19 Dec 2001 13:00:03 +0200
Jussi Mikkola <jussi.mikkola@bonware.com>
Re: 7.2 is slow?
> I haven't tested with the new 7.2 betas, but here are some results from
> 7.1.
> 
> We have a developement computer, IBM x series 250, with 4 processors
> (PIII Xeon 750Mhz), 1 Gb memory and  2SCSI disks (u160).
> 
> The software is writing new rows to a table, and after this it reads the
> id from that row. There are currently about 50 connections doing the
> same thing.
> 
> When I run this test with the Redhat 7.1, with SMP kernel, I noticed, that
> the
> processors are more than 90% idle. Disks utilisation is not the
> bottleneck either, since there is very low disk usage. Some data is
> written to disks every 4-5 seconds. Fsync is turned of. In transactions,
> this means about 200 inserted rows per second. The software that is used
> to give the feed, is capable of several thousand rows per second.
> 
> Okey, so I tried this also with the same computer, but using the not SMP
> supported kernel. So only with one processor. The result was about 600
> rows per second. The configuration file was unchanged. Now, the
> processor is about 100% utilized.
> 
> I didn't find any parameters that should help in this, but if you have a
> version of 7.2 that you would like to get information about, let me
> know, so I'll test.

Yes!  This sleeping case is the problem we expected to see on SMP
machines in >= 7.1 because of lock contention and a select() that can't
sleep for less than 1/100 second.  Please try the current 7.2 snapshot
and let us know what performance you get.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 19 Dec 2001 06:37:04 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: 7.2 is slow?
Hi !

Yes, now I've tested with 7.2b4. The result is about the  same as with 7.1.

About 200 messages with four processors and about 600 messages with one
processor.

Jussi

>
>
> Yes!  This sleeping case is the problem we expected to see on SMP
> machines in >= 7.1 because of lock contention and a select() that can't
> sleep for less than 1/100 second.  Please try the current 7.2 snapshot
> and let us know what performance you get.
>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

--
Jussi Mikkola                    Project Manager
Bonware Oy                       gsm +358 40 830 7561
Tekniikantie 12                  tel +358 9 2517 5570
02150 Espoo                      fax +358 9 2517 5571
Finland                          www.bonware.com




Wed, 19 Dec 2001 14:54:48 +0200
Jussi Mikkola <jussi.mikkola@bonware.com>
Re: 7.2 is slow?
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> Might there also be a difference in chosen query plans ?

If so, it'd affect the results across-the-board, but AFAICT
Tatsuo is seeing comparable results for small numbers of clients.

			regards, tom lane

Wed, 19 Dec 2001 10:05:07 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.2 is slow? 
Hi All,

I have experienced similar problems after moving my main server from UP 
(PII 300 box) to SMP (PII400 box).  I remeber someone said look at the 
iostat figures for the different runs, but I haven't had time to check 
it out.

Out of curosity, what does iostat say when run in SMP vs UP?

Ashley Cambrell

Jussi Mikkola wrote:

>Hi !
>
>Yes, now I've tested with 7.2b4. The result is about the  same as with 7.1.
>
>About 200 messages with four processors and about 600 messages with one
>processor.
>
>Jussi
>
>>
>><snip>
>>



Thu, 20 Dec 2001 02:09:42 +1100
Ashley Cambrell <ash@freaky-namuh.com>
Re: 7.2 is slow?
We're getting similar problem.
We're currently working on TPC-H benchmarking using postgresql 7.2b3.
>From one up to 8 paralell conexions (we've got 8 MIPS processors), uptime
increases from 1 to 8,
but increasing above 8 makes performance drop rapidly to uptimes even lower
than 2 for 22 conexions.
As we've could trail, when we have more processes than processors, we're
getting an increasing number of collisions.
when collision happens both processes get idle for a while, then collision may
happen again and so...
Regards
Luis Amigo
Universidad de Cantabria



Wed, 19 Dec 2001 16:20:40 +0100
Luis Amigo <lamigo@atc.unican.es>
Re: 7.2 is slow?
Jussi Mikkola <jussi.mikkola@bonware.com> writes:
> Yes, now I've tested with 7.2b4. The result is about the  same as with 7.1.

> About 200 messages with four processors and about 600 messages with one
> processor.

That's annoying.  The LWLock changes were intended to solve the
inefficiency with multiple CPUs, but it seems like we still have a
problem somewhere.

Could you recompile the backend with profiling enabled and try to get
a profile from your test case?  To build a profilable backend, it's
sufficient to do

	cd .../src/backend
	gmake clean
	gmake PROFILE=-pg all
	gmake install-bin

(assuming you are using gcc).  Then restart the postmaster, and you
should notice "gmon.out" files being dropped into the various database
subdirectories anytime a backend exits.  Next run your test case,
and as soon as it finishes copy the gmon.out file to a safe place.
(You'll only be able to get the profile from the last process to exit,
so try to make sure that this is representative.  Might be worth
repeating the test a few times to make sure that the results don't
vary a whole lot.)  Finally, do

	gprof .../bin/postgres gmon.out >resultfile

to produce a legible result.

Oh, one more thing: on Linuxen you are likely to find that all the
reported routine runtimes are zero, rendering the results useless.
Apply the attached patch (for 7.2beta) to fix this.

			regards, tom lane

*** src/backend/postmaster/postmaster.c.orig	Wed Dec 12 14:52:03 2001
--- src/backend/postmaster/postmaster.c	Mon Dec 17 19:38:29 2001
***************
*** 1823,1828 ****
--- 1823,1829 ----
  {
  	Backend    *bn;				/* for backend cleanup */
  	pid_t		pid;
+ 	struct itimerval svitimer;
  
  	/*
  	 * Compute the cancel key that will be assigned to this backend. The
***************
*** 1858,1869 ****
--- 1859,1874 ----
  	beos_before_backend_startup();
  #endif
  
+ 	getitimer(ITIMER_PROF, &svitimer);
+ 
  	pid = fork();
  
  	if (pid == 0)				/* child */
  	{
  		int			status;
  
+ 		setitimer(ITIMER_PROF, &svitimer, NULL);
+ 
  		free(bn);
  #ifdef __BEOS__
  		/* Specific beos backend startup actions */

Wed, 19 Dec 2001 10:30:51 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.2 is slow? 
Luis Amigo <lamigo@atc.unican.es> writes:
> We're getting similar problem.
> We're currently working on TPC-H benchmarking using postgresql 7.2b3.
> From one up to 8 paralell conexions (we've got 8 MIPS processors),

MIPS?  Which spinlock implementation is getting used?  (Look in
src/include/storage/s_lock.h and src/backend/storage/lmgr/s_lock.c)

If you're falling back to the default SysV-semaphore based spinlock
implementation, I wouldn't be surprised to see a performance problem...

			regards, tom lane

Wed, 19 Dec 2001 10:44:41 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.2 is slow? 
I haven't actually tried to compile 7.2 from the CVS, but there seems to 
be a problem?  [maybe on my side]

make[3]: Leaving directory 
`/home/ash/ash-server/Work/build/pgsql/src/backend/utils'
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations  
-Wl,-rpath,/tmp//lib -export-dynamic access/SUBSYS.o bootstrap/SUBSYS.o 
catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o 
lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o 
optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o 
rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o -lz 
-lcrypt -lresolv -lnsl -ldl -lm -lreadline  -o postgres
nodes/SUBSYS.o: In function `pprint':
nodes/SUBSYS.o(.text+0xdc95): undefined reference to `MIN'
nodes/SUBSYS.o(.text+0xdcfd): undefined reference to `MIN'
collect2: ld returned 1 exit status
make[2]: *** [postgres] Error 1
make[2]: Leaving directory 
`/home/ash/ash-server/Work/build/pgsql/src/backend'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/ash/ash-server/Work/build/pgsql/src'
make: *** [all] Error 2

In ./src/backend/nodes/print.c:

/* outdent */
if (indentLev > 0)
{
    indentLev--;
    indentDist = MIN(indentLev * INDENTSTOP, MAXINDENT);
}


If I add
#ifndef MIN
#define MIN(a,b) (((a)<(b)) ? (a) : (b))
#endif
to print.c it compiles fine.

Ashley Cambrell


<snip>

>
>That's annoying.  The LWLock changes were intended to solve the
>inefficiency with multiple CPUs, but it seems like we still have a
>problem somewhere.
>
>Could you recompile the backend with profiling enabled and try to get
>a profile from your test case?  To build a profilable backend, it's
>sufficient to do
>
>	cd .../src/backend
>	gmake clean
>	gmake PROFILE=-pg all
>	gmake install-bin
>
>(assuming you are using gcc).  Then restart the postmaster, and you
>should notice "gmon.out" files being dropped into the various database
>subdirectories anytime a backend exits.  Next run your test case,
>and as soon as it finishes copy the gmon.out file to a safe place.
>(You'll only be able to get the profile from the last process to exit,
>so try to make sure that this is representative.  Might be worth
>repeating the test a few times to make sure that the results don't
>vary a whole lot.)  Finally, do
>
>	gprof .../bin/postgres gmon.out >resultfile
>
>to produce a legible result.
>
>Oh, one more thing: on Linuxen you are likely to find that all the
>reported routine runtimes are zero, rendering the results useless.
>Apply the attached patch (for 7.2beta) to fix this.
>
>			regards, tom lane
>
>*** src/backend/postmaster/postmaster.c.orig	Wed Dec 12 14:52:03 2001
>--- src/backend/postmaster/postmaster.c	Mon Dec 17 19:38:29 2001
>***************
>*** 1823,1828 ****
>--- 1823,1829 ----
>  {
>  	Backend    *bn;				/* for backend cleanup */
>  	pid_t		pid;
>+ 	struct itimerval svitimer;
>  
>  	/*
>  	 * Compute the cancel key that will be assigned to this backend. The
>***************
>*** 1858,1869 ****
>--- 1859,1874 ----
>  	beos_before_backend_startup();
>  #endif
>  
>+ 	getitimer(ITIMER_PROF, &svitimer);
>+ 
>  	pid = fork();
>  
>  	if (pid == 0)				/* child */
>  	{
>  		int			status;
>  
>+ 		setitimer(ITIMER_PROF, &svitimer, NULL);
>+ 
>  		free(bn);
>  #ifdef __BEOS__
>  		/* Specific beos backend startup actions */
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/users-lounge/docs/faq.html
>




Thu, 20 Dec 2001 11:51:03 +1100
Ashley Cambrell <ash@freaky-namuh.com>
Re: 7.2 is slow? [compile problem]
I just got the same problem on latest CVS on freebsd/i386

gmake[4]: Entering directory `/home/chriskl/pgsql/src/backend/utils/time'
gcc -pipe -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../.
./src/include   -c -o tqual.o tqual.c
/usr/libexec/elf/ld -r -o SUBSYS.o tqual.o
gmake[4]: Leaving directory `/home/chriskl/pgsql/src/backend/utils/time'
/usr/libexec/elf/ld -r -o SUBSYS.o fmgrtab.o adt/SUBSYS.o cache/SUBSYS.o
error/SUBSYS.o fmgr/SUBSYS.o hash/SUBSYS.o init/SUBSYS.o misc/SUBS
YS.o mmgr/SUBSYS.o sort/SUBSYS.o time/SUBSYS.o
gmake[3]: Leaving directory `/home/chriskl/pgsql/src/backend/utils'
gcc -pipe -O2 -Wall -Wmissing-prototypes -Wmissing-declarations  -R/home/chr
iskl/local/lib -export-dynamic access/SUBSYS.o bootstrap/SUBSYS
.o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o
lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/
SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o
storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o -lz -lcrypt -lcomp
at -lm -lutil -lreadline  -o postgres
nodes/SUBSYS.o: In function `pprint':
nodes/SUBSYS.o(.text+0xda71): undefined reference to `MIN'
nodes/SUBSYS.o(.text+0xdade): undefined reference to `MIN'
gmake[2]: *** [postgres] Error 1
gmake[2]: Leaving directory `/home/chriskl/pgsql/src/backend'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/home/chriskl/pgsql/src'
gmake: *** [all] Error 2

Chris

> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Ashley Cambrell
> Sent: Thursday, 20 December 2001 8:51 AM
> To: Tom Lane
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] 7.2 is slow? [compile problem]
>
>
> I haven't actually tried to compile 7.2 from the CVS, but there seems to
> be a problem?  [maybe on my side]
>
> make[3]: Leaving directory
> `/home/ash/ash-server/Work/build/pgsql/src/backend/utils'
> gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
> -Wl,-rpath,/tmp//lib -export-dynamic access/SUBSYS.o bootstrap/SUBSYS.o
> catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o
> lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o
> optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o
> rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o -lz
> -lcrypt -lresolv -lnsl -ldl -lm -lreadline  -o postgres
> nodes/SUBSYS.o: In function `pprint':
> nodes/SUBSYS.o(.text+0xdc95): undefined reference to `MIN'
> nodes/SUBSYS.o(.text+0xdcfd): undefined reference to `MIN'
> collect2: ld returned 1 exit status
> make[2]: *** [postgres] Error 1
> make[2]: Leaving directory
> `/home/ash/ash-server/Work/build/pgsql/src/backend'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/ash/ash-server/Work/build/pgsql/src'
> make: *** [all] Error 2
>
> In ./src/backend/nodes/print.c:
>
> /* outdent */
> if (indentLev > 0)
> {
>     indentLev--;
>     indentDist = MIN(indentLev * INDENTSTOP, MAXINDENT);
> }
>
>
> If I add
> #ifndef MIN
> #define MIN(a,b) (((a)<(b)) ? (a) : (b))
> #endif
> to print.c it compiles fine.
>
> Ashley Cambrell
>
>
> <snip>
>
> >
> >That's annoying.  The LWLock changes were intended to solve the
> >inefficiency with multiple CPUs, but it seems like we still have a
> >problem somewhere.
> >
> >Could you recompile the backend with profiling enabled and try to get
> >a profile from your test case?  To build a profilable backend, it's
> >sufficient to do
> >
> >	cd .../src/backend
> >	gmake clean
> >	gmake PROFILE=-pg all
> >	gmake install-bin
> >
> >(assuming you are using gcc).  Then restart the postmaster, and you
> >should notice "gmon.out" files being dropped into the various database
> >subdirectories anytime a backend exits.  Next run your test case,
> >and as soon as it finishes copy the gmon.out file to a safe place.
> >(You'll only be able to get the profile from the last process to exit,
> >so try to make sure that this is representative.  Might be worth
> >repeating the test a few times to make sure that the results don't
> >vary a whole lot.)  Finally, do
> >
> >	gprof .../bin/postgres gmon.out >resultfile
> >
> >to produce a legible result.
> >
> >Oh, one more thing: on Linuxen you are likely to find that all the
> >reported routine runtimes are zero, rendering the results useless.
> >Apply the attached patch (for 7.2beta) to fix this.
> >
> >			regards, tom lane
> >
> >*** src/backend/postmaster/postmaster.c.orig	Wed Dec 12 14:52:03 2001
> >--- src/backend/postmaster/postmaster.c	Mon Dec 17 19:38:29 2001
> >***************
> >*** 1823,1828 ****
> >--- 1823,1829 ----
> >  {
> >  	Backend    *bn;				/* for backend cleanup */
> >  	pid_t		pid;
> >+ 	struct itimerval svitimer;
> >
> >  	/*
> >  	 * Compute the cancel key that will be assigned to this backend. The
> >***************
> >*** 1858,1869 ****
> >--- 1859,1874 ----
> >  	beos_before_backend_startup();
> >  #endif
> >
> >+ 	getitimer(ITIMER_PROF, &svitimer);
> >+
> >  	pid = fork();
> >
> >  	if (pid == 0)				/* child */
> >  	{
> >  		int			status;
> >
> >+ 		setitimer(ITIMER_PROF, &svitimer, NULL);
> >+
> >  		free(bn);
> >  #ifdef __BEOS__
> >  		/* Specific beos backend startup actions */
> >
> >---------------------------(end of broadcast)---------------------------
> >TIP 5: Have you checked our extensive FAQ?
> >
> >http://www.postgresql.org/users-lounge/docs/faq.html
> >
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>


Thu, 20 Dec 2001 10:02:42 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: 7.2 is slow? [compile problem]

OK, I just committed a fix.  MIN() was used in the pretty node print
patch;  should have been Min().

---------------------------------------------------------------------------

> I just got the same problem on latest CVS on freebsd/i386
> 
> gmake[4]: Entering directory `/home/chriskl/pgsql/src/backend/utils/time'
> gcc -pipe -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../.
> ./src/include   -c -o tqual.o tqual.c
> /usr/libexec/elf/ld -r -o SUBSYS.o tqual.o
> gmake[4]: Leaving directory `/home/chriskl/pgsql/src/backend/utils/time'
> /usr/libexec/elf/ld -r -o SUBSYS.o fmgrtab.o adt/SUBSYS.o cache/SUBSYS.o
> error/SUBSYS.o fmgr/SUBSYS.o hash/SUBSYS.o init/SUBSYS.o misc/SUBS
> YS.o mmgr/SUBSYS.o sort/SUBSYS.o time/SUBSYS.o
> gmake[3]: Leaving directory `/home/chriskl/pgsql/src/backend/utils'
> gcc -pipe -O2 -Wall -Wmissing-prototypes -Wmissing-declarations  -R/home/chr
> iskl/local/lib -export-dynamic access/SUBSYS.o bootstrap/SUBSYS
> .o catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o
> lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o optimizer/
> SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o rewrite/SUBSYS.o
> storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o -lz -lcrypt -lcomp
> at -lm -lutil -lreadline  -o postgres
> nodes/SUBSYS.o: In function `pprint':
> nodes/SUBSYS.o(.text+0xda71): undefined reference to `MIN'
> nodes/SUBSYS.o(.text+0xdade): undefined reference to `MIN'
> gmake[2]: *** [postgres] Error 1
> gmake[2]: Leaving directory `/home/chriskl/pgsql/src/backend'
> gmake[1]: *** [all] Error 2
> gmake[1]: Leaving directory `/home/chriskl/pgsql/src'
> gmake: *** [all] Error 2
> 
> Chris
> 
> > -----Original Message-----
> > From: pgsql-hackers-owner@postgresql.org
> > [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Ashley Cambrell
> > Sent: Thursday, 20 December 2001 8:51 AM
> > To: Tom Lane
> > Cc: pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] 7.2 is slow? [compile problem]
> >
> >
> > I haven't actually tried to compile 7.2 from the CVS, but there seems to
> > be a problem?  [maybe on my side]
> >
> > make[3]: Leaving directory
> > `/home/ash/ash-server/Work/build/pgsql/src/backend/utils'
> > gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations
> > -Wl,-rpath,/tmp//lib -export-dynamic access/SUBSYS.o bootstrap/SUBSYS.o
> > catalog/SUBSYS.o parser/SUBSYS.o commands/SUBSYS.o executor/SUBSYS.o
> > lib/SUBSYS.o libpq/SUBSYS.o main/SUBSYS.o nodes/SUBSYS.o
> > optimizer/SUBSYS.o port/SUBSYS.o postmaster/SUBSYS.o regex/SUBSYS.o
> > rewrite/SUBSYS.o storage/SUBSYS.o tcop/SUBSYS.o utils/SUBSYS.o -lz
> > -lcrypt -lresolv -lnsl -ldl -lm -lreadline  -o postgres
> > nodes/SUBSYS.o: In function `pprint':
> > nodes/SUBSYS.o(.text+0xdc95): undefined reference to `MIN'
> > nodes/SUBSYS.o(.text+0xdcfd): undefined reference to `MIN'
> > collect2: ld returned 1 exit status
> > make[2]: *** [postgres] Error 1
> > make[2]: Leaving directory
> > `/home/ash/ash-server/Work/build/pgsql/src/backend'
> > make[1]: *** [all] Error 2
> > make[1]: Leaving directory `/home/ash/ash-server/Work/build/pgsql/src'
> > make: *** [all] Error 2
> >
> > In ./src/backend/nodes/print.c:
> >
> > /* outdent */
> > if (indentLev > 0)
> > {
> >     indentLev--;
> >     indentDist = MIN(indentLev * INDENTSTOP, MAXINDENT);
> > }
> >
> >
> > If I add
> > #ifndef MIN
> > #define MIN(a,b) (((a)<(b)) ? (a) : (b))
> > #endif
> > to print.c it compiles fine.
> >
> > Ashley Cambrell
> >
> >
> > <snip>
> >
> > >
> > >That's annoying.  The LWLock changes were intended to solve the
> > >inefficiency with multiple CPUs, but it seems like we still have a
> > >problem somewhere.
> > >
> > >Could you recompile the backend with profiling enabled and try to get
> > >a profile from your test case?  To build a profilable backend, it's
> > >sufficient to do
> > >
> > >	cd .../src/backend
> > >	gmake clean
> > >	gmake PROFILE=-pg all
> > >	gmake install-bin
> > >
> > >(assuming you are using gcc).  Then restart the postmaster, and you
> > >should notice "gmon.out" files being dropped into the various database
> > >subdirectories anytime a backend exits.  Next run your test case,
> > >and as soon as it finishes copy the gmon.out file to a safe place.
> > >(You'll only be able to get the profile from the last process to exit,
> > >so try to make sure that this is representative.  Might be worth
> > >repeating the test a few times to make sure that the results don't
> > >vary a whole lot.)  Finally, do
> > >
> > >	gprof .../bin/postgres gmon.out >resultfile
> > >
> > >to produce a legible result.
> > >
> > >Oh, one more thing: on Linuxen you are likely to find that all the
> > >reported routine runtimes are zero, rendering the results useless.
> > >Apply the attached patch (for 7.2beta) to fix this.
> > >
> > >			regards, tom lane
> > >
> > >*** src/backend/postmaster/postmaster.c.orig	Wed Dec 12 14:52:03 2001
> > >--- src/backend/postmaster/postmaster.c	Mon Dec 17 19:38:29 2001
> > >***************
> > >*** 1823,1828 ****
> > >--- 1823,1829 ----
> > >  {
> > >  	Backend    *bn;				/* for backend cleanup */
> > >  	pid_t		pid;
> > >+ 	struct itimerval svitimer;
> > >
> > >  	/*
> > >  	 * Compute the cancel key that will be assigned to this backend. The
> > >***************
> > >*** 1858,1869 ****
> > >--- 1859,1874 ----
> > >  	beos_before_backend_startup();
> > >  #endif
> > >
> > >+ 	getitimer(ITIMER_PROF, &svitimer);
> > >+
> > >  	pid = fork();
> > >
> > >  	if (pid == 0)				/* child */
> > >  	{
> > >  		int			status;
> > >
> > >+ 		setitimer(ITIMER_PROF, &svitimer, NULL);
> > >+
> > >  		free(bn);
> > >  #ifdef __BEOS__
> > >  		/* Specific beos backend startup actions */
> > >
> > >---------------------------(end of broadcast)---------------------------
> > >TIP 5: Have you checked our extensive FAQ?
> > >
> > >http://www.postgresql.org/users-lounge/docs/faq.html
> > >
> >
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> >
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 19 Dec 2001 21:40:09 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: 7.2 is slow? [compile problem]
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> OK, I just committed a fix.  MIN() was used in the pretty node print
> patch;  should have been Min().

Mea maxima (or MINima?) culpa.  Thanks ...

			regards, tom lane

Wed, 19 Dec 2001 22:18:11 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.2 is slow? [compile problem] 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > OK, I just committed a fix.  MIN() was used in the pretty node print
> > patch;  should have been Min().
> 
> Mea maxima (or MINima?) culpa.  Thanks ...

I also noticed we define our our MAX/MIN in adt/numeric.c and a few
other files.  I put it on my list to research that in 7.3 and maybe use
the c.h versions.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Wed, 19 Dec 2001 22:20:42 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: 7.2 is slow? [compile problem]
Hi Tom!

Well, here's the profile, but yes, almost all the times are zero. Both without
the patch, and with it. Did I miss something? (Yes, I did make and install
afterwards ;-)

I made a new database, so as it was growing, the times were even slower than
before. (It would be nice, if I could create a large database from the
beginning.;)

Is this of any help? Do you need the same result with less cpus?

Jussi


Tom Lane wrote:

> Jussi Mikkola <jussi.mikkola@bonware.com> writes:
> > Yes, now I've tested with 7.2b4. The result is about the  same as with 7.1.
>
> > About 200 messages with four processors and about 600 messages with one
> > processor.
>
> That's annoying.  The LWLock changes were intended to solve the
> inefficiency with multiple CPUs, but it seems like we still have a
> problem somewhere.
>
> Could you recompile the backend with profiling enabled and try to get
> a profile from your test case?  To build a profilable backend, it's
> sufficient to do
>
>         cd .../src/backend
>         gmake clean
>         gmake PROFILE=-pg all
>         gmake install-bin
>
> (assuming you are using gcc).  Then restart the postmaster, and you
> should notice "gmon.out" files being dropped into the various database
> subdirectories anytime a backend exits.  Next run your test case,
> and as soon as it finishes copy the gmon.out file to a safe place.
> (You'll only be able to get the profile from the last process to exit,
> so try to make sure that this is representative.  Might be worth
> repeating the test a few times to make sure that the results don't
> vary a whole lot.)  Finally, do
>
>         gprof .../bin/postgres gmon.out >resultfile
>
> to produce a legible result.
>
> Oh, one more thing: on Linuxen you are likely to find that all the
> reported routine runtimes are zero, rendering the results useless.
> Apply the attached patch (for 7.2beta) to fix this.
>
>                         regards, tom lane
>
> *** src/backend/postmaster/postmaster.c.orig    Wed Dec 12 14:52:03 2001
> --- src/backend/postmaster/postmaster.c Mon Dec 17 19:38:29 2001
> ***************
> *** 1823,1828 ****
> --- 1823,1829 ----
>   {
>         Backend    *bn;                         /* for backend cleanup */
>         pid_t           pid;
> +       struct itimerval svitimer;
>
>         /*
>          * Compute the cancel key that will be assigned to this backend. The
> ***************
> *** 1858,1869 ****
> --- 1859,1874 ----
>         beos_before_backend_startup();
>   #endif
>
> +       getitimer(ITIMER_PROF, &svitimer);
> +
>         pid = fork();
>
>         if (pid == 0)                           /* child */
>         {
>                 int                     status;
>
> +               setitimer(ITIMER_PROF, &svitimer, NULL);
> +
>                 free(bn);
>   #ifdef __BEOS__
>                 /* Specific beos backend startup actions */

--
Jussi Mikkola                    Project Manager
Bonware Oy                       gsm +358 40 830 7561
Tekniikantie 12                  tel +358 9 2517 5570
02150 Espoo                      fax +358 9 2517 5571
Finland                          www.bonware.com
Thu, 20 Dec 2001 15:55:28 +0200
Jussi Mikkola <jussi.mikkola@bonware.com>
Re: 7.2 is slow?
Jussi Mikkola <jussi.mikkola@bonware.com> writes:
> Well, here's the profile, but yes, almost all the times are zero.

It looks to me like this profile only covers the postmaster, not a
backend.  You want to use gmon.out from down inside the database's
subdirectory ($PGDATA/base/something/gmon.out).

> Both without the patch, and with it. Did I miss something? (Yes, I did
> make and install afterwards ;-)

[ scratches head ]  Dunno.  You did restart the postmaster after
installing the new executable, right?

			regards, tom lane

Thu, 20 Dec 2001 09:55:14 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.2 is slow? 
Jussi Mikkola wrote:
> 
> Hi Tom!
> 
> Well, here's the profile, but yes, almost all the times are zero. Both without
> the patch, and with it. Did I miss something? (Yes, I did make and install
> afterwards ;-)
> 
> I made a new database, so as it was growing, the times were even slower than
> before. (It would be nice, if I could create a large database from the
> beginning.;)
> 
> Is this of any help? Do you need the same result with less cpus?
> 
> Jussi
> 
> Tom Lane wrote:
> 
> > Jussi Mikkola <jussi.mikkola@bonware.com> writes:
> > > Yes, now I've tested with 7.2b4. The result is about the  same as with 7.1.
> >
> > > About 200 messages with four processors and about 600 messages with one
> > > processor.
> >

Was this solved with latest LWLock patches ?

--------------
Hannu

Wed, 09 Jan 2002 12:02:42 +0200
Hannu Krosing <hannu@tm.ee>
Re: 7.2 is slow?