Re: Statement-level Triggers For Uniqueness Checks - Mailing list pgsql-hackers
From | Corey Huinker |
---|---|
Subject | Re: Statement-level Triggers For Uniqueness Checks |
Date | |
Msg-id | CADkLM=df6rd4Z4H8MjxHx3gEJkA_983LLc1YQtbzFWafchCyvw@mail.gmail.com Whole thread Raw |
In response to | Statement-level Triggers For Uniqueness Checks (Corey Huinker <corey.huinker@gmail.com>) |
Responses |
Re: Statement-level Triggers For Uniqueness Checks
Re: Statement-level Triggers For Uniqueness Checks |
List | pgsql-hackers |
The regression diff (attached) seems to imply that the triggers simply are not firing, though. I have verified that the triggers are created:
test=# CREATE TEMPORARY TABLE test ( x integer PRIMARY KEY DEFERRABLE INITIALLY DEFERRED );
CREATE TABLE
test=# SELECT * FROM pg_trigger WHERE
oid tgconstraint tgdeferrable tginitdeferred tgnargs tgqual
tgargs tgconstrindid tgenabled tgisinternal tgnewtable tgrelid
tgattr tgconstrrelid tgfoid tgname tgoldtable tgtype
test=# SELECT * FROM pg_trigger WHERE tgrelid = 'test'::regclass;
oid | tgrelid | tgname | tgfoid | tgtype | tgenabled | tgisinternal | tgconstrrelid | tgconstrindid | tgconstraint | t
gdeferrable | tginitdeferred | tgnargs | tgattr | tgargs | tgqual | tgoldtable | tgnewtable
-------+---------+------------------------------+--------+--------+-----------+--------------+---------------+---------------+--------------+--
------------+----------------+---------+--------+--------+--------+------------+------------------------------
16392 | 16387 | PK_ConstraintTrigger_i_16392 | 1250 | 4 | O | t | 0 | 16390 | 16391 | t
| t | 0 | | \x | | | pg_inserted_transition_table
16393 | 16387 | PK_ConstraintTrigger_u_16393 | 1250 | 16 | O | t | 0 | 16390 | 16391 | t
| t | 0 | | \x | | | pg_inserted_transition_table
(2 rows)
In digging around the codebase (see thread: Referential Integrity Checks with Statement-level Triggers), I noticed that unique constraints are similarly enforced with a per-row trigger.The situation with unique indexes is fairly similar to the situation with RI checks: there is some overhead to using a transition table, but that overhead may be less than the cost of firing a trigger once per row inserted/updated.However, there are some significant differences (apologies to everyone already familiar with this part of the code, it's new to me).For one, there is no analog to RI_Initial_Check(). Instead the constraint is initially checked via building/finding the unique index that would enforce the uniqueness check.Then, the actual lookup done in unique_key_recheck has to contend with the intricacies of HOT updates, so I don't know if that can be expressed in an SPI query. Even if not, I think it should be possible to iterate over the EphemeralNamedRelation and that would result itself have a payoff in reduced trigger calls.I'm going to be working on this as a POC patch separate from the RI work, hence the separate thread, but there's obviously a lot of overlap.All advice is appreciated.
Attachment
pgsql-hackers by date: