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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Adding nextval() to a select caused hang/very slow execution
Дата
Msg-id 1237916.1604517808@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Adding nextval() to a select caused hang/very slow execution  (Eric Raskin <eraskin@paslists.com>)
Ответы Re: Adding nextval() to a select caused hang/very slow execution
Список pgsql-performance
Eric Raskin <eraskin@paslists.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



В списке pgsql-performance по дате отправления:

Предыдущее
От: Eric Raskin
Дата:
Сообщение: Re: Adding nextval() to a select caused hang/very slow execution
Следующее
От: Eric Raskin
Дата:
Сообщение: Re: Adding nextval() to a select caused hang/very slow execution