> On Nov 17, 2021, at 10:42 PM, Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> This message originated outside your organization.
>
> On Thu, Nov 18, 2021 at 04:39:42PM +1300, Thomas Munro wrote:
>> On Thu, Nov 18, 2021 at 1:18 PM Robert Creager <robertc@spectralogic.com> wrote:
>>> So, how do I go about capturing more information for the big brains (you guys) to help figure this out? I have all
ourresources at mine (and hence your) disposal.
>>
>> As a workaround, does it help if you issue DISCARD PLANS before your
>> COPY jobs, or alternatively start with a fresh connection? I'm
I can certainly give that a try.
> It also seems to work if one does SET plan_cache_mode=force_custom_plan;
>
> Robert might try that, either in postresql.conf, or SET in the client that's
> doing COPY.
Which would be better? Discard plans or forcing custom plans? Seems like wrapping a copy might be better than the
Postgres.confchange as that would affect all statements. What kind of performance hit would we be taking with that do
youestimate? Microseconds per statement? Yeah, hard to say, depends on hardware and such. Would there be any benefit
overallto doing that? Forcing the replan?
Best,
Robert
