Forgotten to CC the list, sorry... >Well, instead of an explain output which takes 2.4MB compressed and >9.6MB uncompressed (take it as unreadable), could you produce a >self-contained test case with a glimpse of the schema you are using? >Where does the OOM happen, and how did you change your partitioned table >schema? Are you using the native partitioning instead? >Michael, Thank you for your answer.
Sorry for the unreadable explain output. I attached a SQL dump with 2 entities loaded in the database (2,872,265 entities in the actual database), the actual query and the actual output. The OOM is durin the query (SELECT) after ~9 minutes the memory of the postgres increase until 8GB and the OOM message. Partitioning is done by inherhitance. After a complete reload of the database in PG10.4 the OOM still exists. -- Michael
<<attachment: Archive.zip>>
