From: Tom Lane <tgl@sss.pgh.pa.us>
To: dafoer_x@163.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17650: For the sixth time,
 the clipping function in the 120 partition table planning stage fails
In-reply-to: <17650-4523221bc4eb0c33@postgresql.org>
References: <17650-4523221bc4eb0c33@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Tue, 18 Oct 2022 13:11:13 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2601908.1666101938.1@sss.pgh.pa.us>
Date: Tue, 18 Oct 2022 10:05:38 -0400
Message-ID: <2601909.1666101938@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2601909.1666101938%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> The clipping function of partition table cannot be carried out normally in
> the planning stage.

This looks like normal behavior to me: the sixth iteration is where
the plan cache will try to see if a generic plan would be smarter
to use than a custom one.  Unsurprisingly, for a table partitioned
as heavily as this one, it takes a little while even to construct
a generic plan.  Then it'll decide "nope, we'll stick to custom
planning" and the subsequent executions take the same amount of
time as before.

You could override that with "set plan_cache_mode = force_custom_plan".
But TBH my advice is to use fewer partitions.  There are always going
to be edge cases where the system has to consider all the partitions.
If you're allergic to spending even half a dozen msec in the planner,
you need to set up your tables in a way that doesn't require so much
time when that happens.

			regards, tom lane