Unix Technical Forum

Re: Finding bottleneck

This is a discussion on Re: Finding bottleneck within the Pgsql Performance forums, part of the PostgreSQL category; --> > Bill of Materials Traversal ( ~ 62k records). > > ISAM* pg 8.0 pg 8.1 devel delta 8.0->8.1 ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > Pgsql Performance

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-18-2008, 01:15 PM
Merlin Moncure
 
Posts: n/a
Default Re: Finding bottleneck

> Bill of Materials Traversal ( ~ 62k records).
>
> ISAM* pg 8.0 pg 8.1 devel delta 8.0->8.1
> running time 63 sec 90 secs 71 secs 21%
> cpu load 17% 45% 32% 29%
> loadsecs** 10.71 40.5 22.72 44%
> recs/sec 984 688 873
> recs/loadsec 5882 1530 2728
>
> *ISAM is an anonymous commercial ISAM library in an optimized server
> architecture (pg smokes the non-optimized flat file version).
> **Loadsecs being seconds of CPU at 100% load.


One thing that might interest you is that the penalty in 8.1 for
stats_command_string=true in this type of access pattern is very high: I
was experimenting to see if the new cpu efficiency gave me enough of a
budget to start using this. This more than doubled the cpu load to
around 70% with a runtime of 82 seconds. This is actually worse than
8.0 .

This *might* be a somewhat win32 specific issue. I've had issues with
the stats collector before. Anyways, the feature is a frill so it's not
a big deal.

Merlin



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

http://archives.postgresql.org

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 04-18-2008, 01:15 PM
Tom Lane
 
Posts: n/a
Default Re: Finding bottleneck

"Merlin Moncure" <merlin.moncure@rcsonline.com> writes:
> One thing that might interest you is that the penalty in 8.1 for
> stats_command_string=true in this type of access pattern is very high: I
> was experimenting to see if the new cpu efficiency gave me enough of a
> budget to start using this. This more than doubled the cpu load to
> around 70% with a runtime of 82 seconds. This is actually worse than
> 8.0 .


That seems quite peculiar; AFAICS the pgstat code shouldn't be any
slower than before. At first I thought it might be because we'd
increased PGSTAT_ACTIVITY_SIZE, but actually that happened before
8.0 release, so it shouldn't be a factor in this comparison.

Can anyone else confirm a larger penalty for stats_command_string in
HEAD than in 8.0? A self-contained test case would be nice too.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 09:21 AM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
www.UnixAdminTalk.com