>> 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.
it is possible to emulate with plproxy for example.
>
>> 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?
premature optimization ...
>
>> 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.
agreed.
>
>> 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).
at the SQL level, I don't see the immediate benefit given that the
feature is not implemented: SQL level stuff (planner hint) are here
to workaround what the server can not handle on its own. And
PostgreSQL policiy is not to allow planner hint, but to fix/improve
the server.
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation