Thanks for the hin. My bad. The backup db and 9.5 had a different type on one of the foreign-key constrains char(36) vs varchar(36).
The schema was screwed couple of days ago, byt performance numbers I checked only after migration to 9.5. Sorry for the noise. Tigran. ----- Original Message ----- > From: "Tom Lane" <t...@sss.pgh.pa.us> > To: "Andres Freund" <and...@anarazel.de> > Cc: "Mkrtchyan, Tigran" <tigran.mkrtch...@desy.de>, "pgsql-performance" > <pgsql-performance@postgresql.org> > Sent: Sunday, July 5, 2015 4:33:25 PM > Subject: Re: [PERFORM] 9.5alpha1 vs 9.4 > Andres Freund <and...@anarazel.de> writes: >> On 2015-07-05 13:10:51 +0200, Mkrtchyan, Tigran wrote: >>> today I have update my test system to 9.5alpha1. >>> Most of the operations are ok, except delete. >>> I get ~1000 times slower! > >>> 255.88 | 566.11 | 452 | DELETE FROM t_inodes WHERE ipnfsid=$1 AND >>> inlink = ? > >> That certainly should not be the case. Could you show the query plan for >> this statement in both versions? > > EXPLAIN ANALYZE, please. I'm wondering about a missing index on some > foreign-key-involved column. That would show up as excessive time in > the relevant trigger ... > > regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
