Skip site navigation (1) Skip section navigation (2)

performance on update table from a join

From: Jean-Luc Lachance <jllachan(at)nsd(dot)ca>
To: pgsql-sql(at)postgresql(dot)org
Subject: performance on update table from a join
Date: 2002-04-30 20:34:36
Message-ID: 3CCEFFDC.516131CC@nsd.ca (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-sql
I am updating a large (1M+) table from a join.  There is no question the
table has to be sequencially scanned. But, I am surprised that Postgres
would perform the join in order to do the update.

My take is that it should lookup in the "rs" table for a match and then
from this reduced set lookup the "routes" table.

Since it is performing an update, it is fair to assume that there will
be only one record from "routes" that will match the where clause. So,
why waste resources performing the join first?

Or maybe I am not reading the query plan correctly...

THX


nsd=# explain update c set newroute = r.route, route = r.routeno, street
= trim( lpad( r.seqno, 4, '0')), exchangeno = r.exchangeno
nsd-# from routes r, rs s where ( c.stname, c.municipality) =
(s.oldstname, s.oldmuni) and
nsd-# (s.exchangeno, s.stname, s.municipality) = ( r.exchangeno,
r.street, r.municipality) and
nsd-# r.fromno <= c.civic and c.civic <= r.tono and (r.parity =
c.civic%2 or r.parity = -1);
NOTICE:  QUERY PLAN:
 
Hash Join  (cost=109.44..118460.53 rows=1 width=857)
  ->  Seq Scan on c  (cost=0.00..112409.04 rows=1156604 width=519)
  ->  Hash  (cost=109.44..109.44 rows=1 width=338)
        ->  Merge Join  (cost=0.00..109.44 rows=1 width=338)
              ->  Index Scan using routes_str_mun on routes r 
(cost=0.00..52.00 rows=1000 width=152)
              ->  Index Scan using rs_stname on rs s  (cost=0.00..52.00
rows=1000 width=186)
 
EXPLAIN

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2002-04-30 20:49:56
Subject: Re: performance on update table from a join
Previous:From: Tom LaneDate: 2002-04-30 20:04:33
Subject: Re: Bug #652: NAMEDATALEN limitations

pgsql-sql by date

Next:From: Tom LaneDate: 2002-04-30 20:49:56
Subject: Re: performance on update table from a join
Previous:From: Tom LaneDate: 2002-04-30 20:04:33
Subject: Re: Bug #652: NAMEDATALEN limitations

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group