Re: Another weird one with an UPDATE

From: Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>
To: David Griffiths <dgriffiths(at)boats(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Another weird one with an UPDATE
Date: 2003-10-13 10:27:23
Message-ID: 3F8A7E0B.8040202@persistent.co.in
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

David Griffiths wrote:

> 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

I think this is the problem. Is there an index on 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)

In this case of comparing account ids, its using two index scans. In the entity
field though, it chooses a sort. I think there is an index missing. The costs
are also shot up as well.

> Total runtime: 226239.77 msec

Standard performance question. What was the last time these tables/database were
vacuumed. Have you tuned postgresql.conf correctly?

HTH

Shridhar

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Vivek Khera 2003-10-13 13:35:17 Re: further testing on IDE drives
Previous Message Shridhar Daithankar 2003-10-13 09:25:22 Re: Performance, vacuum and reclaiming space, fsm