Re: endless quere when upsert with ON CONFLICT clause

From: Andreas Kretschmer <andreas(at)a-kretschmer(dot)de>
To: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: endless quere when upsert with ON CONFLICT clause
Date: 2019-03-29 16:00:19
Message-ID: 181ab4c1-f2d1-3e58-abbe-e8e8dd5dc3a0@a-kretschmer.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Am 29.03.19 um 15:29 schrieb Stephan Schmidt:
>
> PostgreSQL version: 11.2
> Operating system:   Linux
> Description:
>
> We have a wuite complex CTE which collects data fast enough for us and
> has a ok execution plan.
>
> When we insert the result into a table like
>
> With _/some/_data AS (
>
> SELECT….
>
> ), _/some/_other_data AS (
>
> SELECT ….
>
> )
>
> INSERT INTO table1
>
>                 SELECT *
>
>                 FROM _/some/_other_data
>
> ;
>
> It works quite well and we are happy with it’s performance (arround 10
> seconds).
>
> But as soon as we add an ON  CONFLICT clause  (like below) the queries
> runs for ages and doesnt seem to stop. We usually terminate it after
> 12 Hours
>
> With _/some/_data AS (
>
> SELECT….
>
> ), _/some/_other_data AS (
>
> SELECT ….
>
> )
>
> INSERT INTO table1
>
>                 SELECT *
>
>                 FROM _/some/_other_data
>
> ON CONFLICT (column1, column2) DO
>
> UPDATE
>
>         SET column1 = excluded.columnA,
>
> column2 = excluded.columnB,
>
> .
>
> .
>
> .
>
> ;
>
> Where is the Problem?
>

can you show us the explain (analyse) - plan?

i have tried to reproduce, but it seems okay for me.

test=*# create table bla (i int primary key, t text);
CREATE TABLE
test=*# insert into bla select s, 'name ' || s::text from
generate_series(1, 100000) s;
INSERT 0 100000
test=*# commit;
COMMIT

test=*# explain analyse with foo as (select x.* as i from
generate_series(1, 1000) x) insert into bla select * from foo on
conflict (i) do update set t=excluded.i::text;
                                                          QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------
 Insert on bla  (cost=10.00..30.00 rows=1000 width=36) (actual
time=16.789..16.789 rows=0 loops=1)
   Conflict Resolution: UPDATE
   Conflict Arbiter Indexes: bla_pkey
   Tuples Inserted: 0
   Conflicting Tuples: 1000
   CTE foo
     ->  Function Scan on generate_series x  (cost=0.00..10.00
rows=1000 width=4) (actual time=0.214..0.443 rows=1000 loops=1)
   ->  CTE Scan on foo  (cost=0.00..20.00 rows=1000 width=36) (actual
time=0.220..1.124 rows=1000 loops=1)
 Planning Time: 0.104 ms
 Execution Time: 16.860 ms
(10 rows)

test=*# explain analyse with foo as (select x.* + 10000000 as i from
generate_series(1, 1000) x) insert into bla select * from foo on
conflict (i) do update set t=excluded.i::text;
                                                          QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------
 Insert on bla  (cost=12.50..32.50 rows=1000 width=36) (actual
time=13.424..13.424 rows=0 loops=1)
   Conflict Resolution: UPDATE
   Conflict Arbiter Indexes: bla_pkey
   Tuples Inserted: 1000
   Conflicting Tuples: 0
   CTE foo
     ->  Function Scan on generate_series x  (cost=0.00..12.50
rows=1000 width=4) (actual time=0.079..0.468 rows=1000 loops=1)
   ->  CTE Scan on foo  (cost=0.00..20.00 rows=1000 width=36) (actual
time=0.081..1.325 rows=1000 loops=1)
 Planning Time: 0.052 ms
 Execution Time: 13.471 ms
(10 rows)

test=*#

as you can see, no big difference between the 2 plans.

Regards, Andreas

--
2ndQuadrant - The PostgreSQL Support Company.
www.2ndQuadrant.com

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jinho Jung 2019-03-29 16:06:42 Need advice: Parallel query execution introduces performance regression
Previous Message Merlin Moncure 2019-03-29 15:28:20 Re: LIMIT OFFSET with DB view vs plain SQL