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 22:07:50
Message-ID: 3CCF15B6.D3E145D9@nsd.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-sql

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(at)nsd(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Edward Pilipczuk 2002-05-01 05:25:55 Re: Bug #640: ECPG: inserting float numbers
Previous Message Tom Lane 2002-04-30 21:51:08 Re: performance on update table from a join

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2002-04-30 22:50:24 Re: Out of free buffers... HELP!
Previous Message Tom Lane 2002-04-30 21:51:08 Re: performance on update table from a join