> 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.
This is an option right now for having permanent staging tables for future
join. I mistakenly said ETL while it
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 ano
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
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_TRAN
