| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Robert Creager <robertc(at)spectralogic(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Need help identifying a periodic performance issue. |
| Date: | 2021-11-17 21:01:18 |
| Message-ID: | CA+hUKGKmn0g2nb6W7-kh=iGPLise=sLhiVJjBS+wV1ofDuci4g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Thu, Nov 18, 2021 at 8:28 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Justin Pryzby <pryzby(at)telsasoft(dot)com> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Creager | 2021-11-17 21:54:14 | Re: Need help identifying a periodic performance issue. |
| Previous Message | Robert Creager | 2021-11-17 19:51:49 | Re: Need help identifying a periodic performance issue. |