From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Eric Raskin <eraskin(at)paslists(dot)com> |
Cc: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: Adding nextval() to a select caused hang/very slow execution |
Date: | 2020-11-04 19:23:28 |
Message-ID: | 1237916.1604517808@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Eric Raskin <eraskin(at)paslists(dot)com> writes:
> And, of course, your explanation that inserts will not be parallelized must
> be the reason. I will certainly re-vacuum the tables. I wonder why
> auto-vacuum didn't collect better stats. vacuum analyze <table> is all I
> need, right?
Plain ANALYZE is enough to collect stats; but I doubt that'll improve
matters for you. The problem is basically that the planner can't do
anything with a CASE construct, so you end up with default selectivity
estimates for anything involving a CASE, statistics or no statistics.
You need to try to reformulate the query with simpler join conditions.
> As a last resort, what about a PL/PGSQL procedure loop on the query
> result? Since the insert is very few rows relative to the work the select
> has to do, I could just turn the insert.. select.. into a for loop. Then
> the select could be parallel?
Maybe, but you're still skating on a cliff edge. I think it's pure chance
that the parallelized query is working acceptably well; next month with
slightly different conditions, it might not.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Eric Raskin | 2020-11-04 19:25:00 | Re: Adding nextval() to a select caused hang/very slow execution |
Previous Message | Eric Raskin | 2020-11-04 19:12:07 | Re: Adding nextval() to a select caused hang/very slow execution |