Re: PostgreSQL Parallel Processing !

For security reasons, I cannot put real-time senario into loop,

the one which I gave is an example, if I have solution for this then
same will be applied for real-time senario

We have implemented PARALLEL technology into our database and same
expecting after migration to 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

Concept is, we need window for every process on database and all
together should fit in our window and time-line.

We think PostgreSQL should also upgrade PARALLEL technology at SQL-Query level

On 1/27/12, Thomas Kellerer <spam_eater(at)gmx(dot)net> wrote:
> sridhar bamandlapally, 27.01.2012 05:31:
>> SQL> explain plan for select * from hr.emp ;
>> Explained.
>> PLAN
>> --------------------------------------------------------------------------
>> | 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 |
>> --------------------------------------------------------------------------
>> *WITH PARALLEL Option*
>> SQL> explain plan for select /*+parallel(emp,4)*/ * from hr.emp ;
>> Explained.
>> PLAN
>> ---------------------------------------------------------------------------------
>> | Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
>> Time |
>> ---------------------------------------------------------------------------------
>> | 0 | SELECT STATEMENT | | 7444K| 944M| 4442 (3)|
>> 00:00:54 |
>> | 1 | PX COORDINATOR | | | | |
>> |
>> | 2 | PX SEND QC (RANDOM)| :TQ10000 | 7444K| 944M| 4442 (3)|
>> 00:00:54 |
>> | 3 | PX BLOCK ITERATOR | | 7444K| 944M| 4442 (3)|
>> 00:00:54 |
>> | 4 | TABLE ACCESS FULL| EMP | 7444K| 944M| 4442 (3)|
>> 00:00:54 |
>> ---------------------------------------------------------------------------------
>>
>> In the above plan ( WITH PARALLEL Option )
>> 1. "Cost" has been nearly reduced to 1/4th
>> 2. "CPU" has been reduced
>> 3. "Time" has been nearly reduced to 1/3rd
>
> I have *never* seen the "time" column in the explain plan output come
> anywhere near the actual execution time in Oracle.
>
>
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>