Re: PL/pgSQL Loop Vs. Batch Update

From: David Wheeler <david(at)kineticode(dot)com>
To: pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: PL/pgSQL Loop Vs. Batch Update
Date: 2006-05-03 01:16:56
Message-ID: 4F5A51D9-3740-49F2-AFC5-B2901101FFB9@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On May 2, 2006, at 16:52, David Wheeler wrote:

>> Actually looks pretty good to me. Although is generate_series()
>> being rather slow?
>
> Scratch that:

Bah, dammit, there were no rows in that relevant table. Please
disregard my previous EXPLAIN ANALYZE posts.

I've re-run my script and populated it with 549,815 rows. *Now* let's
see what we've got:

try=# VACUUM;
VACUUM
try=# ANALYZE;
ANALYZE
try=# PREPARE foo(int, int[], int) AS
try-# INSERT INTO entry_coll_tag (entry_id, tag_id, ord )
try-# SELECT $1, $2[gs.ser], gs.ser + $3
try-# FROM generate_series(1, array_upper($2, 1)) AS gs(ser)
try-# WHERE $2[gs.ser] NOT IN (
try(# SELECT tag_id FROM entry_coll_tag ect2
try(# WHERE entry_id = $1
try(# );
PREPARE
try=# explain analyze execute foo(100100, ARRAY
[600001,600002,600003,600004,600005,600006,600007], 0);

QUERY PLAN
------------------------------------------------------------------------
-----------------------------------------------------------------------
Function Scan on generate_series gs (cost=9.68..27.18 rows=500
width=4) (actual time=0.965..1.055 rows=7 loops=1)
Filter: (NOT (hashed subplan))
SubPlan
-> Index Scan using idx_entry_tag_ord on entry_coll_tag ect2
(cost=0.00..9.66 rows=8 width=4) (actual time=0.844..0.844 rows=0
loops=1)
Index Cond: (entry_id = $1)
Trigger for constraint entry_coll_tag_entry_id_fkey: time=3.872 calls=7
Trigger for constraint entry_coll_tag_tag_id_fkey: time=3.872 calls=7
Total runtime: 12.797 ms
(8 rows)

try=# delete from entry_coll_tag where entry_id = 100100;
DELETE 7
try=# explain analyze execute foo(100100, ARRAY
[600001,600002,600003,600004,600005,600006,600007], 0);

QUERY PLAN
------------------------------------------------------------------------
-----------------------------------------------------------------------
Function Scan on generate_series gs (cost=9.68..27.18 rows=500
width=4) (actual time=0.117..0.257 rows=7 loops=1)
Filter: (NOT (hashed subplan))
SubPlan
-> Index Scan using idx_entry_tag_ord on entry_coll_tag ect2
(cost=0.00..9.66 rows=8 width=4) (actual time=0.058..0.058 rows=0
loops=1)
Index Cond: (entry_id = $1)
Trigger for constraint entry_coll_tag_entry_id_fkey: time=0.542 calls=7
Trigger for constraint entry_coll_tag_tag_id_fkey: time=0.590 calls=7
Total runtime: 2.118 ms
(8 rows)

Damn, that seems pretty efficient. I wonder if it's the other
function, then. I'll have to work EXPLAIN ANALYZEing _it_.

Best,

David

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Will Reese 2006-05-03 02:09:14 Re: Killing long-running queries
Previous Message Devrim GUNDUZ 2006-05-03 00:01:16 Re: Killing long-running queries