Re: Adding nextval() to a select caused hang/very slow execution

From: Michael Lewis <mlewis(at)entrata(dot)com>
To: Eric Raskin <eraskin(at)paslists(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql Performance <pgsql-performance(at)lists(dot)postgresql(dot)org>
Subject: Re: Adding nextval() to a select caused hang/very slow execution
Date: 2020-11-04 20:19:53
Message-ID: CAHOFxGr5FWfykQf4QtUOUap-aRBh-Yw4XAOx=m_GTdA2HKMfqw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Nov 4, 2020 at 12:12 PM Eric Raskin <eraskin(at)paslists(dot)com> wrote:

> OK - I see. And to add insult to injury, I tried creating a temporary
> table to store the intermediate results. Then I was going to just do an
> insert... select... to insert the rows. That would de-couple the
> nextval() from the query.
>
> Strangely, the first query I tried it on worked great. But, when I tried
> to add a second set of data with a similar query to the same temporary
> table, it slowed right down again. And, of course, when I remove the
> insert, it's fine.
>

I am not entirely sure I am understanding your process properly, but just a
note- If you are getting acceptable results creating the temp table, and
the issue is just that you get very bad plans when using it in some query
that follows, then it is worth noting that autovacuum does nothing on temp
tables and for me it is nearly always worth the small cost to perform an
analyze (at least on key fields) after creating a temp table, or rather
after inserting/updating/deleting records in a significant way.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Eric Raskin 2020-11-04 20:39:41 Re: Adding nextval() to a select caused hang/very slow execution
Previous Message David Rowley 2020-11-04 20:13:22 Re: Partition pruning with joins