Yes, these were deferrable foreign key constraints.
On Fri, Jan 8, 2021 at 2:05 AM Laurenz Albe
wrote:
> On Thu, 2021-01-07 at 10:49 -0700, Craig Jackson wrote:
> > We had a similar situation recently and saw high commit times that were
> caused
> > by having unindexed foreign key columns when
On Fri, Jan 8, 2021 at 11:52 AM José Arthur Benetasso Villanova <
jose.art...@gmail.com> wrote:
> Do you have standby databases and synchronous_commit = 'remote_apply'?
>
We have standby databases, but synchronous_commit is "on".
I found a pair of unindexed foreign key child tables but they neve
On Thu, Jan 7, 2021 at 3:03 PM Don Seiler wrote:
> On Thu, Jan 7, 2021 at 11:50 AM Craig Jackson
> wrote:
>
>> We had a similar situation recently and saw high commit times that were
>> caused by having unindexed foreign key columns when deleting data with
>> large tables involved. You might ch
By the way, please do not top-post (reply above, quoting the full email
after) in these groups.
On Fri, Jan 8, 2021 at 5:00 AM M Tarkeshwar Rao <
m.tarkeshwar@ericsson.com> wrote:
> Hi all,
>
> As we know, the VACUUM VERBOSE output has a lot of dependencies from
> production end and is indef
Hi all,
As we know, the VACUUM VERBOSE output has a lot of dependencies from production
end and is indefinite as of now. We don’t have any clue till now on why exactly
the auto-vacuum is not working for the table. So we need to have a work around
to move ahead for the time being.
Can you plea
On Thu, 2021-01-07 at 10:49 -0700, Craig Jackson wrote:
> We had a similar situation recently and saw high commit times that were caused
> by having unindexed foreign key columns when deleting data with large tables
> involved.
> You might check to see if any new foreign key constraints have been
