Re: BUG #17650: For the sixth time, the clipping function in the 120 partition table planning stage fails

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: dafoer_x(at)163(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17650: For the sixth time, the clipping function in the 120 partition table planning stage fails
Date: 2022-10-18 14:05:38
Message-ID: 2601909.1666101938@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Mike Fröhner 2022-10-18 18:13:34 Aw: Re:  BUG #17647: 12.12 package has difference on ubuntu 18.04
Previous Message Julien Rouhaud 2022-10-18 13:50:17 Re: BUG #17650: For the sixth time, the clipping function in the 120 partition table planning stage fails