headers
markw | 1 Nov 2003 01:18

OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5

I thought someone might be interested in a data point I have comparing
7.3.4 and 7.4beta5 with results from our DBT-2 workload. Keep in mind I
haven't done much tuning with either version.  The following links have
references iostat, vmstat, sar, readprofile (linux kernel profile), and
oprofile (postgresql profile) statistics.

Results from 7.3.4:
	http://developer.osdl.org/markw/dbt2-pgsql/184/
	- metric 1354.58

Results from 7.4beta5
	http://developer.osdl.org/markw/dbt2-pgsql/188/
	- metric 1446.01

7.4beta5 offers more throughput.  One significant difference I see is in
the oprofile for the database.  For the additional 7% increase in the
metric, there are about 32% less ticks in SearchCatCache.

These are the only database parameters I've explicitly set for each one,
any other differences will be differences in default values:
	- shared_buffers = 40000
	- tcpip_socket = true
	- checkpoint_segments = 200
	- checkpoint_timeout = 1800
	- stats_start_collector = true
	- stats_command_string = true
	- stats_block_level = true
	- stats_row_level = true
	- stats_reset_on_server_start = true
(Continue reading)

Permalink | Reply | 36 comments |
headers
Andrew Dunstan | 1 Nov 2003 01:49
Gravatar

Re: 7.4RC1 planned for Monday


----- Original Message ----- 
From: "Neil Conway" <neilc <at> samurai.com>
To: "Bruce Momjian" <pgman <at> candle.pha.pa.us>
Cc: "Tatsuo Ishii" <t-ishii <at> sra.co.jp>; "Tom Lane" <tgl <at> sss.pgh.pa.us>;
"Joshua Drake" <jd <at> commandprompt.com>; "PostgreSQL Hackers"
<pgsql-hackers <at> postgresql.org>
Sent: Friday, October 31, 2003 6:27 PM
Subject: Re: [HACKERS] 7.4RC1 planned for Monday

> On Thu, 2003-10-30 at 23:13, Bruce Momjian wrote:
> > If we do a short cycle, will we have enough features to justify a
> > release?  We could try to get PITR and Win32 done by January 1 and see
> > if that can happen.
>
> It's worth noting that we've thought about doing "quick" major releases
> in the past, without much success: originally, 7.4 was going to be
> "Win32 + PITR, released in a few months", and look how that turned out
> :-)
>
> Since the cost of migrating to a new major release is more-or-less
> constant (you need a complete initdb+reload whether the release took 3
> weeks or 3 years), I'm still not in favour of a short release cycle. But
> in any case, the whole debate is somewhat academic unless someone does
> the work to get PITR and Win32 done very quickly.
>

You don't have to upgrade to every new release.

Maybe win32 needs to be done against the 7.4 codebase whenever that is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rod Taylor | 1 Nov 2003 02:04
Picon

Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5

Excellent.

I just noticed that most of the numbers in the system are given the
numeric data type. Is there any particular reason you don't use integer
(test enforced?)?

On Fri, 2003-10-31 at 19:18, markw <at> osdl.org wrote:
> I thought someone might be interested in a data point I have comparing
> 7.3.4 and 7.4beta5 with results from our DBT-2 workload. Keep in mind I
> haven't done much tuning with either version.  The following links have
> references iostat, vmstat, sar, readprofile (linux kernel profile), and
> oprofile (postgresql profile) statistics.
> 
> Results from 7.3.4:
> 	http://developer.osdl.org/markw/dbt2-pgsql/184/
> 	- metric 1354.58
> 
> Results from 7.4beta5
> 	http://developer.osdl.org/markw/dbt2-pgsql/188/
> 	- metric 1446.01
> 
> 7.4beta5 offers more throughput.  One significant difference I see is in
> the oprofile for the database.  For the additional 7% increase in the
> metric, there are about 32% less ticks in SearchCatCache.
> 
> These are the only database parameters I've explicitly set for each one,
> any other differences will be differences in default values:
> 	- shared_buffers = 40000
> 	- tcpip_socket = true
> 	- checkpoint_segments = 200
(Continue reading)

Permalink | Reply | 5 comments |
headers
Peter Eisentraut | 1 Nov 2003 04:06
Picon
Gravatar

Problems with whitespace-ignoring diff options

On OpenBSD 3.4, the diff options -b and -w have the interesting feature
(actually listed as a bug) that they ignore whitespace for preparing the
diff, but the exit status will be 1 nonetheless, if the files are at all
different.  This leads to several failures in the current regression
tests, because the expected files are off by some whitespace.

It appears we must not use the options for determining whether the test
failed, only for creating the diff output.  Or does anyone have a better
idea?

--

-- 
Peter Eisentraut   peter_e <at> gmx.net

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to majordomo <at> postgresql.org so that your
      message can get through to the mailing list cleanly
Permalink | Reply | 2 comments |
headers
Peter Eisentraut | 1 Nov 2003 04:36
Picon
Gravatar

Re: Call for port reports

Bruce Momjian writes:

> It is time for people to report their port testing.  Please test against
> current CVS or beta5 and report your 'uname -a'.

This one is OK:

OpenBSD ob.credativ.de 3.4 GENERIC#65 sparc

--

-- 
Peter Eisentraut   peter_e <at> gmx.net

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Permalink | Reply | 0 comments |
headers
Tom Lane | 1 Nov 2003 05:51
Picon

Re: Problems with whitespace-ignoring diff options

Peter Eisentraut <peter_e <at> gmx.net> writes:
> It appears we must not use the options for determining whether the test
> failed, only for creating the diff output.  Or does anyone have a better
> idea?

AFAIK, there is no reason to ignore whitespace in determining whether a
test succeeded.  However, if a test fails, it is quite likely that a
whitespace-sensitive diff will produce many lines of uninteresting diff,
because of psql's habit of justifying column output --- any difference
in the data value length where the actual difference occurs would impact
all the rest of the query output, even though it's really "the same".

So if you can implement the above behavior easily, go for it.

Keep in mind though that a reported failure accompanied by *no* visible
diff would be highly annoying ;-).  Can we arrange to produce a
whitespace-sensitive diff output if the whitespace-insensitive kind
shows nothing?

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org
Permalink | Reply | 1 comment |
headers
Bruce Momjian | 1 Nov 2003 06:16
Picon

Re: Vacuum thoughts

Neil Conway wrote:
> On Mon, 2003-10-27 at 15:31, Jan Wieck wrote:
> > Well, "partial solution" isn't quite what I would call it, and it surely 
> > needs integration with sequential scans. I really do expect the whole 
> > hack to fall apart if some concurrent seqscans are going on
> 
> I'd rather see us implement a buffer replacement policy that considers
> both frequency + recency (unlike LRU, which considers only recency).
> Ideally, that would work "automagically". I'm hoping to get a chance to
> implement ARC[1] during the 7.5 cycle.

Someone just started working on it this week.  He emailed Jan and I.  He
hopes to have a patch in a few days.  I will make sure he posts to
hackers/patches.

--

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman <at> candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
Permalink | Reply | 0 comments |
headers
Tom Lane | 1 Nov 2003 06:19
Picon

Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5

markw <at> osdl.org writes:
> 7.4beta5 offers more throughput.  One significant difference I see is in
> the oprofile for the database.  For the additional 7% increase in the
> metric, there are about 32% less ticks in SearchCatCache.

Hmm.  I have been profiling PG for some years now, and I cannot remember
ever seeing a profile in which SearchCatCache topped everything else
(the usual suspects for me are palloc/pfree support code).  Can you give
any explanation why it looks like that?  Can your profiling code tell
where the hotspot call sites of SearchCatCache are?

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
Permalink | Reply | 27 comments |
headers
Richard Schilling | 1 Nov 2003 10:49

Re: postmaster startup failure

I ran into this too.  Patched the code with Tom's change and it works fine.

Thanks again Tom!

Richard Schilling

On 2003.07.17 11:04 Hannu Krosing wrote:
> Tom Lane kirjutas N, 17.07.2003 kell 19:49:
> > Ugh.  The reason we hadn't seen this happen in the field was that it is
> > a bug I introduced in a patch two months ago :-(
> > 
> > 7.3.3 will in fact fail to start up, with the above error, any time the
> > last record of the WAL file ends exactly at a page boundary.  I think
> > we're gonna need a quick 7.3.4 ...
> > 
> > If you want a source patch for 7.3.3, here it is.
> 
> Thanks!
> 
> -----------
> Hannu
> 
> 
> ---------------------------(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
> 

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
(Continue reading)

Permalink | Reply | 0 comments |
headers
Manfred Spraul | 1 Nov 2003 11:44

Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5

markw <at> osdl.org wrote:

>Results from 7.4beta5
>	http://developer.osdl.org/markw/dbt2-pgsql/188/
>	- metric 1446.01
>  
>

CPU: P4 / Xeon with 2 hyper-threads, speed 1497.51 MHz (estimated)
Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01
(count cycles when processor is active) count 100000
samples  %        app name                 symbol name
15369575  9.6780  postgres                 SearchCatCache
13714258  8.6357  vmlinux                  .text.lock.signal
10611912  6.6822  vmlinux                  do_sigaction
4400461   2.7709  vmlinux                  rm_from_queue

18% cpu time in the kernel signal handlers.

What are signals used for by postgres? I've seen the sigalarm to 
implement timeouts, what else?

--
    Manfred

---------------------------(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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane