you will have to modify the example but it may give an
> idea where to start.
>
> Klaus
>
> > -Ursprüngliche Nachricht-
> > Von: Artur Formella
> > Gesendet: Dienstag, 3. April 2018 22:01
> > An: pgsql-general@lists.postgresql.org
> > Betreff: Concu
l 2018 22:01
> An: pgsql-general@lists.postgresql.org
> Betreff: Concurrent CTE
>
> Hello!
> We have a lot of big CTE (~40 statements, ~1000 lines) for very dynamic OLTP
> content and avg response time 50-300ms. Our setup has 96 threads (Intel
> Xeon Gold 6128), 256 GB RAM
On Thu, Apr 5, 2018 at 5:16 PM, David G. Johnston
wrote:
> On Wed, Apr 4, 2018 at 10:12 PM, Thomas Munro
> wrote:
>>
>> Parallel query can't be used for CTE queries currently.
>
> A pointer to the location in the docs covering this limitation would be
> appreciated. It isn't covered here:
>
> ht
On Wed, Apr 4, 2018 at 10:12 PM, Thomas Munro wrote:
> Parallel query can't be used for CTE queries currently.
A pointer to the location in the docs covering this limitation would be
appreciated. It isn't covered here:
https://www.postgresql.org/docs/10/static/when-can-parallel-query-be-used
On Wed, Apr 4, 2018 at 8:01 AM, Artur Formella wrote:
> Execution now:
> time-->
> Thread1: aa | bb | cc | dd | ee | ff | gg | hh | primary
>
> And the question: is it possible to achieve more concurrent execution plan
> to reduce the response time? For example:
> Thread1: aa | dd | ff | primary
>
On Tuesday, April 3, 2018, Artur Formella wrote:
>
> And the question: is it possible to achieve more concurrent execution plan
> to reduce the response time? For example:
> Thread1: aa | dd | ff | primary
> Thread2: bb | ee | gg
> Thread3: cc | -- | hh
>
If and how depends greatly on your versi
On Wed, Apr 4, 2018 at 3:20 AM Artur Formella wrote:
> Hello!
> We have a lot of big CTE (~40 statements, ~1000 lines) for very dynamic
> OLTP content and avg response time 50-300ms. Our setup has 96 threads
> (Intel Xeon Gold 6128), 256 GB RAM and 12 SSD (3 tablespaces). DB size <
> RAM.
> Simpl
Hello!
We have a lot of big CTE (~40 statements, ~1000 lines) for very dynamic
OLTP content and avg response time 50-300ms. Our setup has 96 threads
(Intel Xeon Gold 6128), 256 GB RAM and 12 SSD (3 tablespaces). DB size <
RAM.
Simplifying the problem:
WITH aa as (
SELECT * FROM table1
), bb
