From: | Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | sridhar bamandlapally <sridhar(dot)bn1(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PostgreSQL Parallel Processing ! |
Date: | 2012-01-27 14:38:53 |
Message-ID: | CAF6yO=3G+dNdNid=wZ1mi=--opV2eqEq+70eCBYTgxD4SQvszQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2012-01-27 15:47:09 | Re: pl/pgsql functions outperforming sql ones? |
Previous Message | Jayashankar K B | 2012-01-27 13:34:15 | Postgress is taking lot of CPU on our embedded hardware. |