Are triggers really that slow in Postgres?

Re:Are triggers really that slow in Postgres? by RussianCow on Tuesday May 22, 2018 @09:12PM (#17130813)

Based on the experience of co-workers (and my own limited dabbling), you are right that version control is (and should be) used for stored procedures just as it is with application code. The problem is that there isn't a lot of tooling that isn't language- or platform-specific to help maintain these things in the long run. So DBAs tend to write and maintain their own collection of homegrown scripts for deploying changes to the DB (or worse, do it by hand).

I'm sure some companies have this figured out, though, so YMMV.

[ Parent | on HN ]

Re:Are triggers really that slow in Postgres? by combatentropy on Tuesday May 22, 2018 @11:25PM (#17131287)

I just make files of pure SQL to define the functions, keeping them in Git. I feed them into the psql command-line tool.

[ Parent | on HN ]

Re:Are triggers really that slow in Postgres? by nathanaldensr on Tuesday May 22, 2018 @09:33PM (#17130893)

I certainly figured it out at several jobs:

- Scripts are numbered for quick order determination by humans (e.g., 0001-initial-schema.sql, 0002-create-foo-table.sql)

- A scripts.json file containing an array of string filenames declares the exact order of scripts, just in case numbers are shared for some reason (say, two branches being merged at the same time with a new script in them)

- A custom PowerShell module knows how to read scripts.json and the files and execute the changes

- When possible, all scripts are executed transactionally by the CI tool (some commands in some RDBMSes can't be executed in transactions, however)

- Optionally, backups/restores may be performed to handle failures

[ Parent | on HN ]

Re:Are triggers really that slow in Postgres? by zzzzzzzza on Wednesday May 23, 2018 @12:36AM (#17131502)

isn't this what sqitch does, manages deploying the changes to the db? Anyone have experience with sqitch?

[ Parent | on HN ]