Nick Stanish

Same issue. Excluding node_modules from babel-loader fixed it. ``` module: { loaders: [ { test: /\.jsx?$/, exclude: /(node_modules)/, loader: 'babel-loader' } ] } ```

I added a few indexes which seems to have helped - at least to prevent statement timeouts in the initial dashboard load. ```ruby add_index :good_jobs, :queue_name, if_not_exists: true, algorithm: :concurrently...

Would there be value in shifting from a materialized CTE to a materialized table so that it doesn't need to be computed as frequently? Or perhaps locking larger batches of...

I believe this is a [materialized CTE](https://github.com/bensheldon/good_job/blob/27eb283a3ce89a4858ed3cdb8488863597d11411/app/models/concerns/good_job/advisory_lockable.rb#L55) in the query here: ``` WHERE "good_jobs"."id" IN ( WITH "rows" AS MATERIALIZED ( ``` And pg docs about materialized CTEs: https://www.postgresql.org/docs/current/queries-with.html#QUERIES-WITH-CTE-MATERIALIZATION. If...

@bensheldon Would it be easier to merge both configuration changes without any migrations? I'm unsure how we should handle it since the configuration values could be changed at any time...

@bensheldon I did more benchmarking with ordering by the `scheduled_at` too and I'm seeing 16-76% faster processing I added the results here https://github.com/nickstanish/good_job/pull/1