Search Postgresql Archives

second CTE kills perf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I'm trying to understand this behaviour and the limits of CTE, when they reach the limits, when they cannot receive parameters from a caller, ... I'm running a query on PostgreSQL 10 with a cte. the query runs in ~ 10 seconds. If I add a second CTE with the same query as the previous one and select * from second_cte as query, it now runs in ~ 10 minutes.

oversimplified example:
10 seconds version:
| WITH cte1 AS (SELECT x,y,z FROM table) SELECT row_number() over(),x,y,z FROM cte1 WHERE x=32;

10 minutes version:
| WITH cte1 AS (SELECT x,y,z FROM table), cte2 AS (SELECT row_number() over(),x,y,z FROM cte1) SELECT * FROM cte2 WHERE x=32;

The real examples, with query plans:
https://explain.dalibo.com/plan/98A
https://explain.dalibo.com/plan/o6X4

Thanks for your time,

Nicolas Seinlet.

Attachment: publickey - nicolas@seinlet.com - 0xCAEB7FAF.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux