Re: Slow update - index problem?

From: Greg Copeland <greg(at)CopelandConsulting(dot)Net>
To: Christopher Murtagh <christopher(dot)murtagh(at)mcgill(dot)ca>
Cc: PostgresSQL General Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: Slow update - index problem?
Date: 2003-02-21 19:00:48
Message-ID: 1045854047.17955.60.camel@mouse.copelandconsulting.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Considering that tgl_upd doesn't appear to be indexed, I wouldn't expect
the indexes to even be an issue here.

I completely agree with Tom that it seems like a "VACUUM FULL VERBOSE"
is in order. If you're still confused as to what is going on, doing a,
"EXPLAIN ANALYZE update ind set tgl_upd = 'f';", may also help give a
better picture. I fully expect it to say something like, "Seq Scan on
ind...".

Regards,

Greg Copeland

On Fri, 2003-02-21 at 10:07, Christopher Murtagh wrote:
> I'm trying to perform a very simple update that is very slow. I suspect
> that it is a key/index problem, but we've tried a number of things and
> we're stumped. The table is:
>
> Column | Type | Modifiers
> ---------+------------------------+---------------------------------------
> ind_id | integer | default nextval('"ind_id_seq"'::text)
> bnr_id | integer | not null
> jim_id | integer |
> fnm | character varying(40) |
> nnm | character varying(40) |
> mnm | character varying(40) |
> mdn | character varying(40) |
> lnm | character varying(40) |
> cnm | character varying(200) |
> ord | character varying(80) |
> eml | character varying(80) |
> stf_id | character varying(9) |
> std_id | character varying(9) |
> tgl_upd | boolean |
> Indexes: ind_pkey primary key btree (bnr_id),
> ind_std_id_key unique btree (std_id),
> ind_stf_id_key unique btree (stf_id),
> ind_fnm_idx btree (fnm),
> ind_ind_id_idx btree (ind_id),
> ind_lnm_idx btree (lnm),
> ind_ord_idx btree (ord)
>
> and the query:
>
> update ind set tgl_upd = 'f';
>
> The table has 19867 records, and this query takes over 20 minutes. When I
> export the data to a new DB, with the same table (no indexes) it takes
> about 3 seconds.
>
> Any ideas? Would *removing* indexes make it faster? If so, this sounds
> strange. Any help/info would be much appreciated.
>
> Cheers,
>
> Chris
--
Greg Copeland <greg(at)copelandconsulting(dot)net>
Copeland Computer Consulting

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Diogo de Oliveira Biazus 2003-02-21 19:04:52 Problem with functional indexes
Previous Message Cristian Custodio 2003-02-21 18:59:50 Re: Mutating table (urgent)