Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id CBBB41259185 for ; Fri, 27 Jan 2012 05:19:32 -0400 (AST) Received: from mail-bk0-f46.google.com ([209.85.214.46]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Rqhy0-00040X-8G for pgsql-performance@postgresql.org; Fri, 27 Jan 2012 09:19:32 +0000 Received: by bkas6 with SMTP id s6so1196455bka.19 for ; Fri, 27 Jan 2012 01:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=w0yZAETvLga98fgcKQQTtpm/iS/sUUyT7OsIC1Fm6Jk=; b=uwQl1hIB+jE+HZdSbCDAGCipVVAgyzxtSgVzF3/30ODe3g5fDj42WTdCwFpFX8UCSr PrajnRXBH+pXtvWFVZKiUKPXSjLvwn3z8rus3ZRUT35WLW2e3dZYAj6XpHwGyeMTegHr z0+NFkQHGa+okLuy4dAycDDlE30BZouRcfvWU= Received: by 10.204.129.220 with SMTP id p28mr2731456bks.8.1327655959187; Fri, 27 Jan 2012 01:19:19 -0800 (PST) Received: from [10.64.1.26] ([94.45.140.16]) by mx.google.com with ESMTPS id fb7sm14909728bkc.9.2012.01.27.01.19.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jan 2012 01:19:18 -0800 (PST) Message-ID: <4F226C1D.3020905@gmail.com> Date: Fri, 27 Jan 2012 11:19:25 +0200 From: Vitalii Tymchyshyn User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: PostgreSQL Parallel Processing ! References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Pg-Spam-Score: -2.3 (--) X-Archive-Number: 201201/81 X-Sequence-Number: 46093 27.01.12 11:06, Marti Raudsepp написав(ла): > On Fri, Jan 27, 2012 at 06:31, sridhar bamandlapally > wrote: >> -------------------------------------------------------------------------- >> | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | >> -------------------------------------------------------------------------- >> | 0 | SELECT STATEMENT | | 7444K| 944M| 16077 (4)| 00:03:13 | >> | 1 | TABLE ACCESS FULL| EMP | 7444K| 944M| 16077 (4)| 00:03:13 | >> -------------------------------------------------------------------------- > Sorry to take this off topic, but... Seriously, over 3 minutes to read > 944 MB of data? That's less than 5 MB/s, what's wrong with your > database? :) Actually I'd ask how parallel CPU may help table sequence scan? Usually sequence scan does not take large amount of cpu time, so I see no point in parallelism.