Re: Parallel queries in single transaction

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Paul Muntyanu <pmuntyanu(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parallel queries in single transaction
Date: 2018-07-16 12:28:54
Message-ID: f6cd6f06-80d2-72ed-65e0-139711e92eaf@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07/16/2018 12:03 PM, Paul Muntyanu wrote:
> Hi Tomas, thanks for looking into. I am more talking about queries which
> can not be optimized, e.g.
> * fullscan of the table and heavy calculations for another one.
> * query through FDW for both queries(e.g. one query fetches data from
> Kafka and another one is fetching from remote Postgres. There are no
> bounds for both queries for anything except local CPU, network and
> remote machine)
>
> IO bound is not a problem in case if you have multiple tablesapces.

But it was you who mentioned "query stuck" not me. I merely pointed out
that in such cases running queries concurrently won't help.

> And CPU bound can be not the case when you have 32 cores and 6 max workers
> per query. Then, during nigtly ETL, I do not have anything except single
> query running) == 6 cores are occupied. If I can run queries in
> parallel, I would occupy two IO stacks(two tablespaces) + 12 cores
> instead of sequentially 6 and then again 6.
>

Well, sure. But you could just as well open multiple connections and
make the queries concurrent that way. Or change the GUC to increase the
number of workers for the nightly ETL.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2018-07-16 12:29:37 Re: Finding database for pg_upgrade missing library
Previous Message Tomas Vondra 2018-07-16 12:23:52 Re: [HACKERS] PATCH: multivariate histograms and MCV lists