Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 98AAC1259185 for ; Fri, 27 Jan 2012 08:44:07 -0400 (AST) Received: from elizabeth.gransy.com ([89.187.132.199]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Rql9w-0007Zc-FT for pgsql-performance@postgresql.org; Fri, 27 Jan 2012 12:44:07 +0000 Received: from sq.gransy.com (localhost [127.0.0.1]) by elizabeth.gransy.com (Postfix) with ESMTP id E271C15E4119; Fri, 27 Jan 2012 13:43:49 +0100 (CET) Received: from 85.163.76.202 (SquirrelMail authenticated user tv@fuzzy.cz) by sq.gransy.com with HTTP; Fri, 27 Jan 2012 13:43:49 +0100 Message-ID: <192f81363e2bd10a4d9a1d0741c54674.squirrel@sq.gransy.com> In-Reply-To: References: Date: Fri, 27 Jan 2012 13:43:49 +0100 Subject: Re: PostgreSQL Parallel Processing ! From: "Tomas Vondra" To: "sridhar bamandlapally" Cc: pgsql-performance@postgresql.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201201/85 X-Sequence-Number: 46097 On 27 Leden 2012, 13:16, sridhar bamandlapally wrote: > For security reasons, I cannot put real-time senario into loop, The point of Marti's comment was that the estimates (as presented by EXPLAIN PLAN FOR in Oracle) are inherently imprecise. Don't trust what Oracle is telling you about the expected runtime of the queries. Run the queries repeatedly to see. > the one which I gave is an example, if I have solution for this then > same will be applied for real-time senario There's no way to execute a single query in a parallel manner and it won'= t be available anytime soon. This is not an issue unless you have a CPU bound query and you have unuse= d CPUs. That's not the case of your example, because the sequential scan is likely to be I/O bound, thus executing it in parallel won't fix the issue= . > We have implemented PARALLEL technology into our database and same > expecting after migration to PostgreSQL, Why? Have you tried to run the query on PostgreSQL? > The real-time SQL-Query is hiting 18000 times per day, and PARALLEL > option gave us great performance and big window for all other process Are we still discussing the example you've posted? Because this 18k hits per day means running the query every 5 seconds. And if the query takes more than a few seconds, there will be multiple queries running concurrently, thus eating CPUs. > Concept is, we need window for every process on database and all > together should fit in our window and time-line. Not sure what you mean by window or time-line? > We think PostgreSQL should also upgrade PARALLEL technology at SQL-Quer= y > level That is currently discussed in other threads, but it won't happen any tim= e soon (a few years in the future, maybe). Tomas