From: Tom Lane <tgl@sss.pgh.pa.us>
To: Benjamin Tingle <ben@tingle.org>
cc: pgsql-performance@postgresql.org
Subject: Re: Query Planner not taking advantage of HASH PARTITION
In-reply-to: 
 <CABTcpyvPwQekzDfFbDAV-=B00ks76YrtbZLE-Jcb2Q5h1+JdyQ@mail.gmail.com>
References: 
 <CABTcpyvoSYrn-2S4p8hRwAsCe3PkOUS4dFxmr6gUy4x9u5PDKA@mail.gmail.com>
 <2132751.1650211749@sss.pgh.pa.us>
 <CABTcpyvPwQekzDfFbDAV-=B00ks76YrtbZLE-Jcb2Q5h1+JdyQ@mail.gmail.com>
Comments: In-reply-to Benjamin Tingle <ben@tingle.org>
	message dated "Sun, 17 Apr 2022 10:07:50 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2143748.1650219624.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 17 Apr 2022 14:20:24 -0400
Message-ID: <2143749.1650219624@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2143749.1650219624%40sss.pgh.pa.us>
Precedence: bulk

Benjamin Tingle <ben@tingle.org> writes:
> Interesting. Why is it impossible to prune hash partitions? Maybe prune
> isn=E2=80=99t the best word, more so use to advantage. At the very least=
, it should
> be possible to utilize a parallel insert against a table partitioned by
> hash. (Partition query rows, then distribute these rows to parallel work=
ers)

Your plan-shape complaint had nothing to do with insertions; it had
to do with joining the partitioned table to another table.  That
join can't be optimized.

			regards, tom lane