Investigate ci_builds <-> taggings relation in connection to partitioning
We use tags to allow runner selection for builds. This is implemented by using the acts-as-taggable-on
gem and it defines a polymorphic relation with the Ci::Build
model as tagger_id
and tagger_type
:
Table "public.taggings"
Column | Type | Collation | Nullable | Default | Storage | Stats target | Description
---------------+-----------------------------+-----------+----------+--------------------------------------+----------+--------------+-------------
tag_id | integer | | | | plain | |
taggable_type | character varying | | | | extended | |
tagger_id | integer | | | | plain | |
tagger_type | character varying | | | | extended | |
context | character varying | | | | extended | |
created_at | timestamp without time zone | | | | plain | |
id | bigint | | not null | nextval('taggings_id_seq'::regclass) | plain | |
taggable_id | bigint | | | | plain | |
Indexes:
"taggings_pkey" PRIMARY KEY, btree (id)
"taggings_idx" UNIQUE, btree (tag_id, taggable_id, taggable_type, context, tagger_id, tagger_type)
"index_taggings_on_tag_id" btree (tag_id)
"index_taggings_on_taggable_id_and_taggable_type_and_context" btree (taggable_id, taggable_type, context)
Access method: heap
This holds a reference to the ci_builds
table without defining a foreign key and ci_builds
is not the only user of this table, ci_runners
has entries too. A couple of questions that needs to be answered:
- Do we try to find builds starting from the tags part of the relation?
- Should we add a
partition_id
column to this table?