From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756083AbYEWSq0 (ORCPT ); Fri, 23 May 2008 14:46:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751373AbYEWSqQ (ORCPT ); Fri, 23 May 2008 14:46:16 -0400 Received: from westnet.com ([216.187.52.2]:53313 "EHLO westnet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751196AbYEWSqP (ORCPT ); Fri, 23 May 2008 14:46:15 -0400 Date: Fri, 23 May 2008 14:46:13 -0400 (EDT) From: Greg Smith X-X-Sender: gsmith@westnet.com To: Anton Petrusevich cc: lkml Subject: Re: PostgreSQL pgbench performance regression in 2.6.23+ In-Reply-To: <200805231326.44247.casus@casus.us> Message-ID: References: <200805231326.44247.casus@casus.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 23 May 2008, Anton Petrusevich wrote: > Excuse me for interrupting you, but am I getting this right: to run > effectively PostgreSQL with an active web app on the server a "system > administrator Joe" has to know about batch scheduling? That's not true. The problem here is specifically with the pgbench program, which is a simple benchmarking tool included with PostgreSQL. pgbench already had known scalability problems due to its inefficient design and the new scheduler really doesn't play well with it by default. It's the pgbench program that needs the batch scheduling, not the database processes. pgbench is certainly not representative of web application performance, and it wouldn't be the first time there was some OS tweaking required to get good results from such an artificial benchmark. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD