set enable_nestloop=off did the trick. Execution time when down to seconds
per query.
Thanks very much for your help.
On Wed, Nov 4, 2020 at 4:16 PM Tom Lane wrote:
> Eric Raskin writes:
> > So, things get even weirder. When I execute each individual select
> > statement
psql command line?
On Wed, Nov 4, 2020 at 3:20 PM Michael Lewis wrote:
> On Wed, Nov 4, 2020 at 12:12 PM Eric Raskin 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
&
OK -- got it. Thanks very much for your help. I'll see what I can do to
denormalize the case statements into actual columns to support the queries.
On Wed, Nov 4, 2020 at 2:23 PM Tom Lane wrote:
> Eric Raskin writes:
> > And, of course, your explanation that inserts will not b
ect.. into a for loop. Then
the select could be parallel?
What do you think?
On Wed, Nov 4, 2020 at 2:01 PM Tom Lane wrote:
> Eric Raskin writes:
> > And, to follow up on your question, the plan shape DOES change when I
> > add/remove the nextval() on a plain explain.
>
And, to follow up on your question, the plan shape DOES change when I
add/remove the nextval() on a plain explain.
Without nextval(): https://explain.depesz.com/s/SCdY
With nextval(): https://explain.depesz.com/s/oLPn
On Wed, Nov 4, 2020 at 1:22 PM Eric Raskin wrote:
> Thanks for
st unnest().
In the real application, this code feeds an insert statement with a trigger
that accesses the sequence where we store the results of the query. I
"simplified" it and discovered that the nextval() was the difference that
caused the performance hit.
Eric
On Wed, Nov 4, 2020
SORRY! Here's a link that should show the plan:
https://explain.depesz.com/s/SCdY
--
exes:
"glmproducts$pk" PRIMARY KEY, btree (prodcode)
Referenced by:
TABLE ""glm$autoship"" CONSTRAINT "glm$autoship$prodfk" FOREIGN KEY
(itemcode) REFERENCES glm.glmproducts(prodcode)
TABLE ""glm$tracking"" CONSTRAINT "glm$
