Re: Hung Query with No Locking Issues

From: "Michael P(dot) McDonnell" <bzaks1424(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Hung Query with No Locking Issues
Date: 2023-05-07 23:42:21
Message-ID: CAHmCLHrsd81NLtOD9zpGjQc+Csn94bjxsXSmK1UBsLcFPkSA7Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Okay - that worked.
How did you know that would work? That's incredible.

On Sun, May 7, 2023 at 4:25 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Michael P. McDonnell" <bzaks1424(at)gmail(dot)com> writes:
> > I have 2 stored procedures that need to run back to back. It could
> > convert to a single one - but it's easier from a maintenance perspective
> to
> > keep them separated.
>
> > The first procedure effectively is
> > INSERT INTO table_b () SELECT ____ FROM _table_a_;
> > COMMIT;
>
> > Total execution time - about 180s. Nothing in the pg_locks table and
> > nothing in the pg_stat_activity table suggests anything is hung over.
>
> > The second procedure mutates table_b data into table_b_collapsed
> > INSERT INTO table_c () SELECT _____ FROM _table_b_ JOIN _table_b as b1_
> > JOIN _table_b as b2_ JOIN _table_b as b3_, etc...;
> > COMMIT;
>
> > The first time I run my second stored procedure - it hangs for up to 8
> > hours.
> > If I immediately cancel and re-run the second stored procedure it runs
> in 2
> > seconds.
>
> Perhaps an "ANALYZE table_b" in between would help.
>
> regards, tom lane
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2023-05-08 01:00:17 Re: Hung Query with No Locking Issues
Previous Message Tom Lane 2023-05-07 21:25:34 Re: Hung Query with No Locking Issues