Don't fire referential integrity triggers if primary or unique keys haven't changed

[gsbelarus]

We encountered the following issue on a large database:

#8593

We needed to update a table containing 172 million records. The update did not modify the primary key of any records — it only updated three integer fields. However, since the table was referenced by 1,358 foreign keys, the operation triggered:

1.72 × 10⁸ × 1.358 × 10³ ≈ 10¹¹

system trigger calls. These trigger calls alone caused the update to take 19 hours.

The proposed solution is to skip referential integrity triggers when the primary key or any other unique key is not modified.

[hvlad]

Build artifacts for test: https://github.com/FirebirdSQL/firebird/actions/runs/15650342142

[gsbelarus]

Now it takes just 13 minutes. Huge improvement. THANKS!

PLAN (GD_DOCUMENT NATURAL)

172274304 record(s) was(were) updated in GD_DOCUMENT

------ Performance info ------
Prepare time = 844ms
Execute time = 13m 30s 406ms
Current memory = 62 035 504
Max memory = 155 639 184
Memory buffers = 4 000
Reads from disk to cache = 3 308 448
Writes from cache to disk = 3 299 537
Fetches from cache = 1 392 584 970

[hvlad]

Good to know, thanks.

Could you check if this build doesn't broke RI handling ? I.e. cascading operations works as expected.
I've run basic tests before commit, but you may have more extensive tests, probably.

[gsbelarus]

I'll deploy this build to the production servers. But don't rely on us too much — we don't support operations where the primary key is changed for existing records or where foreign keys reference a unique key that is not the primary key.

[sim1984]

I think Pavel Zotov will take this into account in the tests.