In my Rails 6 app, I'm creating a table that I know will get large. So I'm partitioning it by month using pg_partman. It's hosted on Heroku, so I've followed their instructions. The migration looks something like this:
class CreateReceipts < ActiveRecord::Migration[6.0]
def change
reversible do |dir|
dir.up do
execute <<-SQL
create extension pg_partman;
SQL
end
dir.down do
execute <<-SQL
drop extension pg_partman;
SQL
end
end
create_table(
:receipts,
# Partitioning requires the primary key includes the column we're partitioning by.
primary_key: [:id, :created_at],
options: 'partition by range (created_at)'
) do |t|
# When using the primary key option, it ignores id: true. Make the ID column manually.
t.column :id, :bigserial, null: false
t.references :customer, null: false, foreign_key: true
t.integer :thing, null: false
t.text :stuff, null: false
t.timestamps
end
reversible do |dir|
dir.up do
execute <<-SQL
select create_parent('public.receipts', 'created_at', 'native', 'monthly');
SQL
end
dir.down do
# Dropping receipts undoes all the partitioning, except the template table.
drop_table(:template_public_receipts)
end
end
end
end
class Receipt < ApplicationRecord
# The composite primary key is only for partitioning.
self.primary_key = 'id'
# Unfortunately, partitioning gets confused if we add another unique index.
# So we must enforce ID uniqueness in the model.
validates :id, uniqueness: true
end
A little weird with the primary key, but it works fine locally. Heroku Postgres has the pg_partman extension, so production is fine.
The problem is HerokuCI. I'm using the recommended in-dyno database add on. It does not have pg_partman
.
-----> Preparing test database
Running: rake db:schema:load_if_ruby
db:schema:load_if_ruby completed (6.17s)
Running: rake db:structure:load_if_sql
set_config
------------
(1 row)
psql:/app/db/structure.sql:16: ERROR: could not open extension control file "/app/.indyno/vendor/postgresql/share/extension/pg_partman.control": No such file or directory
rake aborted!
failed to execute:
I'd rather not having to attach a full database to CI just for this one thing. And it feels strange to hard code the pg_partman partitions into the schema, though it is good to have the tests as close to production as possible.
Is there an alternative approach?