Hi,
On 07/16/2018 09:45 AM, Paul Muntyanu wrote:
> Hello,
>
> I am working with data warehouse based on postgresql and would like
> to propose a feature. The idea is to give control and ability for
> developer to execute queries in parallel within single transaction.
> Usual flow is next: START_TRANSACTION -> QUERY1 -> QUERY2 -> QUERY3 ->
> END_TRANSACTION. However sometimes QUERY1 and QUERY2 are independent and
> can be executed in parallel mode. E.g.: START_TRANSACTION ->
> DEFINE_QUERY1(no execution) -> DEFINE_QUERY2(no_execution) ->
> EXECUTE_QUERY1_AND_QUERY2(in parallel) -> QUERY3 -> END
>
> Of course QUERY1 and QUERY2 can be dependent and then this would not
> work, but sometimes it is useful, especially when you have bound to e.g.
> CPU and query stuck.
I'm struggling to understand what would be the possible benefits. Either
the queries are CPU-bound or stuck (e.g. waiting for I/O), they can't be
both at the same time. If a query is stuck, running it concurrently is
pointless. If they are CPU-bound, we can run them in parallel (which
should produce the results faster).
I'd even dare to say that running the queries concurrently can easily
hinder performance, because the queries will compete for parallel
workers, preventing some of them from running in parallel mode.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services