Cory Tucker writes:
>> Can you extract a self-contained test case that uses unreasonable amounts
>> of memory? It seems from this trace that the wheels are coming off in
>> at least two places, but identifying exactly where is impossible without
>> more info.
> I will try to make a test case. T
>
> You are running the query (DELETE statement) as if the table is not
> partitioned which is causing the server to crash.
>
> Please run that query for each partitions separately in a loop with
> dynamic query and you should see the improvement. It should be pretty quick.
>
>
I understand that I
>
> Can you extract a self-contained test case that uses unreasonable amounts
> of memory? It seems from this trace that the wheels are coming off in
> at least two places, but identifying exactly where is impossible without
> more info.
>
I will try to make a test case. The data in this table i
Cory Tucker writes:
> I was issuing a query on both databases to cleanup some duplicates in
> preparation of applying new indexes. On the 9.6 database with all the data
> in one table, the query runs fine in about 6 min. On 10.3, with a work_mem
> setting of 1GB the query runs for about 7 minute
.
From: Kumar, Virendra
Sent: Wednesday, March 28, 2018 5:57 PM
To: Cory Tucker; pgsql-gene...@postgresql.org
Subject: RE: Query Crashes PG 10.3 using partitions, works on 9.6
Would be nice if you can attach explain plan of course, explain analyze is not
going to work if server is crashing.
Regards
Would be nice if you can attach explain plan of course, explain analyze is not
going to work if server is crashing.
Regards,
Virendra
From: Cory Tucker [mailto:cory.tuc...@gmail.com]
Sent: Wednesday, March 28, 2018 5:49 PM
To: pgsql-gene...@postgresql.org
Subject: Query Crashes PG 10.3 using pa
