From: | Duncan Sands <duncan(dot)sands(at)deepbluecap(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Query planning on partitioned table causes postgres 13.4 to consume all memory |
Date: | 2021-09-20 12:10:17 |
Message-ID: | 98598292-22bb-1304-656f-773f3677a0a8@deepbluecap.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi Tom,
On 19/09/2021 18:03, Tom Lane wrote:
> Duncan Sands <duncan(dot)sands(at)deepbluecap(dot)com> writes:
>> [ planning DELETE on a thousand-partition table takes forever ]
>
> FWIW, this situation has been very much improved for v14 [1].
thanks, part (2) of that commit indeed looks like it should solve it.
Best wishes, Duncan.
> In older branches, the best advice I can give you is "don't use
> so many partitions". Especially not with hash partitioning,
> where the query WHERE clause generally won't translate to any
> useful pruning of the partitions.
>
> (Personally, I think that hash partitioning is an evil that
> we shouldn't have implemented at all. Or at least there
> should be stronger warnings about it in the manual than there
> are now.)
>
> regards, tom lane
>
> [1] https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=86dc90056
>
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2021-09-20 19:00:02 | BUG #17197: Assert failed on inserting index tuples after VACUUM |
Previous Message | PG Bug reporting form | 2021-09-20 06:14:56 | BUG #17196: old_snapshot_threshold is not honored if there is a transaction |