Re: performance on update table from a join

Tom,

There is no index on c right now, and there aren't any tiggers, rules or
foreign index on any of the tables.

"rs" has 10941 rows ans "routes" has 13928.

JLL

Tom Lane wrote:
> 
> Jean-Luc Lachance <jllachan@nsd.ca> writes:
> > 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)
> 
> Okay, those numbers look more believable.
> 
> Offhand this seems like a perfectly fine plan to me; computing the
> r/s join once and forming it into an in-memory hashtable seems better
> than probing the r and s tables again for each of 1M+ rows of c.
> If the planner is way off about the size of that join (ie, it's not
> 1365 rows but many more) then maybe this isn't a good plan --- but you
> haven't given us any info about that.
> 
> > 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);
> 
> That routes index could be used for the mergejoin if you had a
> corresponding index on rs (ie, one on exchangeno,stname,municipality).
> Not sure that this would make any significant improvement though.
> Merging on street name is probably plenty good enough.
> 
> My thought is that the plan is fine, and if you are having a performance
> problem with the update, it's more likely due to operations triggered by
> the update rather than anything the planner can alter.  Do you have
> rules, triggers, foreign keys on the c table, foreign keys pointing to
> that table, a large number of indexes for that table?
> 
>                         regards, tom lane