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@xxxxxxx> 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@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
