Re: performance on update table from a join

Поиск
Список
Период
Сортировка
От Jean-Luc Lachance
Тема Re: performance on update table from a join
Дата
Msg-id 3CCF0DFE.1B0E583D@nsd.ca
обсуждение исходный текст
Ответ на performance on update table from a join  (Jean-Luc Lachance <jllachan@nsd.ca>)
Ответы Re: performance on update table from a join  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@nsd.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


В списке pgsql-sql по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: performance on update table from a join
Следующее
От: Tom Lane
Дата:
Сообщение: Re: performance on update table from a join