On Mon, 2003-10-13 at 14:43, David Griffiths wrote:
> I've been having performance issues with Postgres (sequential scans vs
> index scans in an update statement). I've read that optimizer will
> change it's plan based on the resources it thinks are available. In
> addition, I've read alot of conflicting info on various parameters, so
> I'd like to sort those out as well.
>  
> Here's the query I've been having problems with:
>  
> UPDATE user_account SET last_name='abc'
> FROM commercial_entity ce, commercial_service cs
> WHERE user_account.user_account_id = ce.user_account_id AND
> ce.commercial_entity_id=cs.commercial_entity_id;
>  
> or 
>  
> UPDATE user_account SET last_name = 'abc'
>  WHERE EXISTS (SELECT 1 FROM commercial_entity ce, commercial_service
> cs
>  WHERE user_account.user_account_id = ce.user_account_id AND
>  ce.commercial_entity_id = cs.commercial_entity_id);
>  
> Both are about the same.
> 
> All columns are indexed; all column-types are the same
> (numeric(10,0)). A vacuum analyze was run just before the last attempt
> at running the above statement.

First thing is to change ce.user_account_id, ce.commercial_entity_id,
and cs.commercial_entity_id from numeric(10,0) to INTEGER.  PG uses
them much more efficiently than it does NUMERIC, since it's a simple
scalar type.

-- 
-----------------------------------------------------------------
Ron Johnson, Jr. [EMAIL PROTECTED]
Jefferson, LA USA

LUKE: Is Perl better than Python?
YODA: No... no... no. Quicker, easier, more seductive.
LUKE: But how will I know why Python is better than Perl?
YODA: You will know. When your code you try to read six months
from now.


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Reply via email to