Re: Another weird one with an UPDATE

From: David Griffiths <dgriffiths(at)boats(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Another weird one with an UPDATE
Date: 2003-10-13 06:23:33
Message-ID: 098b01c39152$921632e0$6501a8c0@griffiths2
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

It's a slight improvement, but that could be other things as well.

I'd read that how you tune Postgres will determine how the optimizer works
on a query (sequential scan vs index scan). I am going to post all I've done
with tuning tommorow, and see if I've done anything dumb. I've found some
contradictory advice, and I'm still a bit hazy on how/why Postgres trusts
the OS to do caching. I'll post it all tommorow.

----------------------------------------------------------------------------
----------------------------------------------------------------------------
----------------
Merge Join (cost=11819.21..15258.55 rows=12007 width=752) (actual
time=4107.64..5587.81 rows=20880 loops=1)
Merge Cond: ("outer".commercial_entity_id = "inner".commercial_entity_id)
-> Index Scan using comm_serv_comm_ent_id_i on commercial_service cs
(cost=0.00..3015.53 rows=88038 width=12) (actual time=0.05..487.23
rows=88038 loops=1)
-> Sort (cost=11819.21..11846.08 rows=10752 width=740) (actual
time=3509.07..3955.15 rows=25098 loops=1)
Sort Key: ce.commercial_entity_id
-> Merge Join (cost=0.00..9065.23 rows=10752 width=740) (actual
time=0.18..2762.13 rows=7990 loops=1)
Merge Cond: ("outer".user_account_id =
"inner".user_account_id)
-> Index Scan using user_account_pkey on user_account
(cost=0.00..8010.39 rows=72483 width=716) (actual time=0.05..2220.86
rows=72483 loops=1)
-> Index Scan using comm_ent_usr_acc_id_i on
commercial_entity ce (cost=0.00..4787.69 rows=78834 width=24) (actual
time=0.02..55.64 rows=7991 loops=1)
Total runtime: 226239.77 msec
(10 rows)

David

----- Original Message -----
From: "Stephan Szabo" <sszabo(at)megazone(dot)bigpanda(dot)com>
To: "David Griffiths" <dgriffiths(at)boats(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Sent: Sunday, October 12, 2003 6:48 PM
Subject: Re: [PERFORM] Another weird one with an UPDATE

> On Sun, 12 Oct 2003, David Griffiths wrote:
>
> > [snip]
> >
> > > I think you want something like:
> > > 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);
> >
> > Unfort, this is still taking a long time.
>
> Hmm, does
> 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;
> give the right results... That might end up being faster.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Andriy Tkachuk 2003-10-13 07:32:03 Re: IMMUTABLE function's flag do not work: 7.3.4, plpgsql
Previous Message David Griffiths 2003-10-13 06:21:24 Re: Another weird one with an UPDATE