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$
SORRY! Here's a link that should show the plan:
https://explain.depesz.com/s/SCdY
--
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
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
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.
>
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
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
&
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
