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
