This message originated outside your organization.
On Thu, Nov 18, 2021 at 8:28 AM Tom Lane < tgl@xxxxxxxxxxxxx> wrote:
Justin Pryzby <pryzby@xxxxxxxxxxxxx> writes:
It shows that the process is running FK triggers.
Indeed, and doing a seqscan therein. Normally I'd suppose that
this reflects a lack of an index, but RI_FKey_check should always
be doing something that matches the referenced table's unique
constraint, so why isn't it using that?
I wonder if the reference tables are empty sometimes, and there's an
unlucky sequence of events that results in cached RI plans with seq
scans being used later in the same session after the tables are
populated.
We are able to move up to Postgres 13.5, in our ports tree, if that would help. We used pg_upgrade to get from 9.6 to 13.3, so that should work fine going instead to 13.5. We’re almost branching/releasing our code, so it’s not a good time, but if it may help
with this problem, we’ll deal with it.
It seems to be important (so far) that we delete a ‘bucket’ in the re-creation of this problem. I’ve included a graphical copy of the schema courtesy of DataGrip. We’re trying to get the problem reproducible more quickly, but at the moment, it takes hours.
|
