Re: Slow update with simple query

[Arnaud Lesauvage <thewild(at)freesurf(dot)fr>]

Ragnar a écrit :
> On mið, 2006-12-13 at 14:38 +0100, Arnaud Lesauvage wrote:
> > Jens Schipkowski a écrit :
> > > On Wed, 13 Dec 2006 13:23:41 +0100, Arnaud Lesauvage <thewild(at)freesurf(dot)fr>  
> > >> Why is this query better than the other one ? Because it runs the  
> > >> "(field IN ('some','other') AND field2 = 'Y')" once and then executes  
> > >> the join with the resulting set ?
> > > True. The Subselect in FROM clause will be executed once and will be  
> > > joined using the condition at where clause. So your condition at t2 is not  
> > > executed for each row in t1(2mio records) but for each row in t2(1k  
> > > records). And the boolean value is already set during update.
> >
> > OK Jens, thanks for clarifying this.
> > I thought the planner could guess what to do in such cases.
>
> don't worry, it will.
> this is not your problem

Indeed, the new query does not perform that well :

"Hash Join  (cost=112.75..307504.97 rows=2024869 width=355) (actual time=53.995..246443.811 rows=2020061 loops=1)"
"  Hash Cond: ("outer".uid = "inner".uid)"
"  ->  Seq Scan on t1 (cost=0.00..261792.01 rows=2033001 width=338) (actual time=19.342..234304.499 rows=2033001 loops=1)"
"  ->  Hash  (cost=110.20..110.20 rows=1020 width=53) (actual time=4.853..4.853 rows=1020 loops=1)"
"        ->  Seq Scan on t2  (cost=0.00..110.20 rows=1020 width=53) (actual time=0.017..2.586 rows=1020 loops=1)"
"Total runtime: 2777844.892 ms"

I removed all unnecessary indexes on t1 before running the query (I left the index on uid and the multicolumn index containind the updated field).
I believe the multicolumn-functional-index computation is taking some time here, isn't it ?

Regards
--
Arnaud