Re: 8.1beta3 performance

From: "PostgreSQL" <martin(at)portant(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: 8.1beta3 performance
Date: 2005-11-02 09:32:45
Message-ID: dka140$1rt4$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

I'm seeing some other little oddities in the beta as well. I'm watching an
ALTER TABLE ADD COLUMN right now that has been running almost two hours. I
stopped it the first time at 1 hour; I suppose I'll let it go this time and
see if it ever completes. The table is about 150K rows. Top, vmstat, and
iostat show almost no cpu or disk activity (1 to 3%) - it's as if it just
went to sleep.

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in message
news:26529(dot)1130865883(at)sss(dot)pgh(dot)pa(dot)us(dot)(dot)(dot)
> Jon Brisbin <jon(dot)brisbin(at)npcinternational(dot)com> writes:
>> I have a stock FreeBSD 5.4 box that I put 8.1 on last night. I ran
>> pgbench against it and my tps dropped from ~300tps in 8.0.3 to 20tps
>> in 8.1. That's right. 20. No changes in any system configuration.
>
> You sure about that last? These numbers are kind of consistent with the
> idea that fsync is off in the 8.0 database and on in the 8.1 database.
>
> Using the same test case you mention (pgbench -s 10, -c 25 -t 1000),
> I find that 8.1 is a bit faster than 8.0, eg
>
> 8.1 fsync off:
> tps = 89.831186 (including connections establishing)
> tps = 89.865065 (excluding connections establishing)
>
> 8.1 fsync on:
> tps = 74.865078 (including connections establishing)
> tps = 74.889066 (excluding connections establishing)
>
> 8.0 fsync off:
> tps = 80.271338 (including connections establishing)
> tps = 80.302054 (excluding connections establishing)
>
> 8.0 fsync on:
> tps = 67.405708 (including connections establishing)
> tps = 67.426546 (excluding connections establishing)
>
> (All database parameters are defaults except fsync.)
>
> These numbers are with assert-enabled builds, on a cheap PC whose drive
> lies about write-complete, so they're not very representative of the
> real world I suppose. But I'm sure not seeing any 10x degradation.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Gavin Sherry 2005-11-02 10:16:27 Re: pgbench results interpretation?
Previous Message Tom Lane 2005-11-02 04:20:52 Re: performance of implicit join vs. explicit conditions on inet queries?