Re: Performance Killer 'IN' ?

Tom Lane wrote:
> Kai Hessing <kai(dot)hessing(at)hobsons(dot)de> writes:
>> Index Scan using phon_phon_idx on phon (cost=0.00..5193.83 rows=530
>> width=148) (actual time=0.146..0.146 rows=0 loops=1)
>> ...
>> Seq Scan on phon (cost=0.00..1573304.58 rows=105931 width=148) (actual
>> time=369563.565..369563.565 rows=0 loops=1)
>
> You need to look into the discrepancy between estimated and actual row
> counts. (I suppose the reason you're showing 0 rows here is that you
> already did these UPDATEs and so none of the rows in question pass the
> status filter --- but how many rows are there matching the phon index
> conditions?) Perhaps a larger statistics target for the phon column
> would be a good idea.

Yes... The 0 rows are there because I did the command before. Now I
resetted the test database to a previous state and dopped the 'AND
status>-1' in the SQL-syntax:

Using the 'UPDATE xyz WHERE id IN ('xyz1', 'xyz2', other 2000
values.....)' returns:
----------------------------
Seq Scan on phon (cost=0.00..1564960.67 rows=317227 width=148) (actual
time=68.315..365621.761 rows=2522 loops=1)

Filter: (((phon)::text = '.....

Total runtime: 393182.745 ms
----------------------------

(please see also the other post <49ck9sFo32mbU1(at)individual(dot)net> )

What do you mean with larger statistics target?