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 unused 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-Query > level That is currently discussed in other threads, but it won't happen any time soon (a few years in the future, maybe). Tomas -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
