Re: Really slow UPDATE and DELETE - Mailing list pgsql-general

From Ryan Mahoney
Subject Re: Really slow UPDATE and DELETE
Date
Msg-id 5.0.2.1.0.20010731180342.034ddc60@paymentalliance.net
Whole thread Raw
In response to Re: Really slow UPDATE and DELETE  (Nicholas Piper <nick@nickpiper.co.uk>)
Responses Re: Really slow UPDATE and DELETE
List pgsql-general
Did you run VACUUM ANALYZE on you database since creating the indexes?

If not, go ahead, and then run your queries again and see if that does the
trick.

-r

At 10:12 PM 7/31/01 +0100, Nicholas Piper wrote:

>On Tue, 31 Jul 2001, Tom Lane wrote:
>
> > Nicholas Piper <nick@nickpiper.co.uk> writes:
> > > Inserts and selects on this table are really fast with indexes, and
> > > pretty fast without.
> > > The problem I'm having is that UPDATES and DELETEs are really, really
> > > slow.
>
> > I'm guessing that you have other tables that have foreign-key references
> > to this one.  The performance problem comes from searching those tables
> > to see if they have any keys that would become dangling references after
> > the update or delete.  You need to look at whether the queries used by
> > the FK triggers are properly indexed or not.
>
>There are; 6.
>
>Prices
>         CONSTRAINT cst_Products_ID FOREIGN KEY (fk_products_id)
> REFERENCES products(id)
>          ON DELETE CASCADE ON UPDATE CASCADE
>Barcodes
>         CONSTRAINT cst_Products_ID FOREIGN KEY (fk_products_id)
> REFERENCES products(id)
>          ON DELETE CASCADE ON UPDATE CASCADE
>Stock
>         CONSTRAINT cst_Products_ID FOREIGN KEY (fk_products_id)
> REFERENCES products(id)
>          ON DELETE RESTRICT ON UPDATE CASCADE,
>         CONSTRAINT cst_AnalysisCode_ID FOREIGN KEY (fk_analysiscode_id)
> REFERENCES analysiscode(id)
>          ON DELETE RESTRICT ON UPDATE CASCADE
>Distributors
>         CONSTRAINT cst_Products_ID FOREIGN KEY (fk_products_id)
> REFERENCES products(id)
>          ON DELETE CASCADE ON UPDATE CASCADE
>BookedOut
>         CONSTRAINT cst_Products_ID FOREIGN KEY (fk_products_id)
> REFERENCES products(id)
>          ON DELETE RESTRICT ON UPDATE CASCADE
>BookedIn
>         CONSTRAINT cst_Products_ID FOREIGN KEY (fk_products_id)
> REFERENCES products(id)
>          ON DELETE RESTRICT ON UPDATE CASCADE
>
>Each fk_products_id column didn't have an index due to either a
>mistake (barcodes should have, but I put an extra one on prices
>instead!) or because of little data (eg. BookedOut/In are empty, so is
>stock).
>
>I've now got these indexes which mention fk columns;
>
>-- Prices
>CREATE INDEX idx_prices_fk_products_id on prices (fk_products_id);
>-- Barcodes
>CREATE INDEX idx_barcodes_fk_products_id on barcodes (fk_products_id);
>-- Stock
>CREATE INDEX idx_stock_fk_products_id on stock (fk_products_id);
>CREATE INDEX idx_stock_fk_analysiscode_id on stock (fk_analysiscode_id);
>-- Distributors
>CREATE INDEX idx_distributors_fk_products_id on distributors (fk_products_id);
>-- BookedOut
>CREATE INDEX idx_bookedout_fk_products_id on bookedout (fk_products_id);
>-- BookedIn
>CREATE INDEX idx_bookedin_fk_products_id on bookedin (fk_products_id);
>
>As well as keys held by products being indexed via;
>
>CREATE INDEX idx_products_fk_company_id on products (fk_company_id);
>CREATE INDEX idx_products_label_id on products (fk_label_id);
>CREATE INDEX idx_products_fk_formats_id on products (fk_formats_id);
>CREATE INDEX idx_products_fk_descriptions_id on products (fk_descriptions_id);
>CREATE INDEX idx_products_fk_genre_id on products (fk_genre_id);
>CREATE INDEX idx_products_fk_variant_id on products (fk_variant_id);
>
>But no change! The simple UPDATE
>   UPDATE products SET title = 'I D THE FIRM' WHERE id = '6';
>still takes over 10 seconds.
>
>Why does this use FK columns at all ? I'm not changing the id, which
>is the pkey for this table.
>
>I'm going to turn up debugging in case that will allow me to see all
>the work PG is putting into my title UPDATE.
>
>  Nick
>
>--
>Part 3 MEng Cybernetics; Reading, UK       http://www.nickpiper.co.uk/
>Change PGP actions of mailer or fetch key see website   1024D/3ED8B27F
>Choose life. Be Vegan :-) Please reduce needless cruelty + suffering !
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: if posting/reading through Usenet, please send an appropriate
>subscribe-nomail command to majordomo@postgresql.org so that your
>message can get through to the mailing list cleanly
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.251 / Virus Database: 124 - Release Date: 4/26/01

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.251 / Virus Database: 124 - Release Date: 4/26/01

pgsql-general by date:

Previous
From: "Mihai Gheorghiu"
Date:
Subject: Corrupted tables?
Next
From: Nicholas Piper
Date:
Subject: Re: Really slow UPDATE and DELETE