Re: performance on update table from a join

From: Jean-Luc Lachance <jllachan(at)nsd(dot)ca>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: performance on update table from a join
Date: 2002-04-30 21:34:54
Message-ID: 3CCF0DFE.1B0E583D@nsd.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-sql

Fair enough.

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=1943.04..136718.39 rows=100 width=660)
-> Seq Scan on c (cost=0.00..112409.04 rows=1156604 width=519)
-> Hash (cost=1939.63..1939.63 rows=1365 width=141)
-> Merge Join (cost=0.00..1939.63 rows=1365 width=141)
-> Index Scan using routes_str_mun on routes r
(cost=0.00..1053.46 rows=13928 width=77)
-> Index Scan using rs_stname on rs s (cost=0.00..704.11
rows=10942 width=64)

EXPLAIN

I have also the following indecies that are ot being used:
create index routes_ex_str_mun on routes( exchangeno, street,
municipality);
create index rs_ostr_omun on rs( oldstname, oldmuni);

Tom Lane wrote:
>
> Jean-Luc Lachance <jllachan(at)nsd(dot)ca> writes:
> > 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)
>
> Have you vacuum analyzed routes and rs? I always disbelieve any plan
> with 'rows=1000' in it, because I know that's the default assumption
> when no stats are available...
>
> regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2002-04-30 21:51:08 Re: performance on update table from a join
Previous Message Tom Lane 2002-04-30 20:49:56 Re: performance on update table from a join

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2002-04-30 21:51:08 Re: performance on update table from a join
Previous Message Tom Lane 2002-04-30 20:49:56 Re: performance on update table from a join