Re: [PERFORM] Re: Adding foreign key constraint holds exclusive lock for too long (on production database)

2013-10-31 Thread Ben Hoyt
Thanks, Tom (and David and Josh). Well, apparently nobody who knows the code was paying attention, because that hasn't been true for some time. ALTER TABLE ADD FOREIGN KEY will actually validate the constraint using a query constructed like this (cf RI_Initial_Check() in ri_triggers.c):

Re: [PERFORM] Re: Adding foreign key constraint holds exclusive lock for too long (on production database)

2013-10-31 Thread Tom Lane
Ben Hoyt benh...@gmail.com writes: It appears the possible explanations for Ben's problem are: 1. For some reason this query is a lot slower than the one he came up with; Anyway, it's definitely #1 that's happening, as I build the RI_Initial_Check() query by hand, and it takes just as long

[PERFORM] Update Trigger latency utilizing the IS DISTINCT FROM syntax

2013-10-31 Thread fburgess
if we have the following trigger:CREATE TRIGGER admin_update_triggerBEFORE UPDATE ON admin_logger_overflowFOR EACH ROW WHEN ((old.start_date_time IS DISTINCT FROM new.start_date_time)) EXECUTE PROCEDURE update_logger_config();and the database call issues an: update admin_logger_overflow set

Re: [PERFORM] Re: Adding foreign key constraint holds exclusive lock for too long (on production database)

2013-10-31 Thread Ben Hoyt
Hmm, weird -- now the RI_Initial_Check() query is much quicker (20s). We do ANALYZE the data every few nights, so maybe that's what changed it. I'll keep that in mind. -Ben On Fri, Nov 1, 2013 at 3:19 AM, Tom Lane t...@sss.pgh.pa.us wrote: Ben Hoyt benh...@gmail.com writes: It appears the