Reply To: Delete Row in repeater of 250+ very slow

• John Huebner

• May 19, 2023 at 9:10 am

You cannot delete a row through MySQL, this will break the repeater. An explanation of why it takes so long and why it will break things to delete.

The database contains multiple entries. The repeater itself has a meta_key value of "{$repeater_name}" and this DB entry holds the number of rows in the repeater. Each sub field has a meta_key value of "{$repeater_name}_{$row_index}_{$sub_field_name}"

Now lets say that you want to delete row 100 of 250 rows. All of the rows past 100 need to be re-saved. First meta key "{$repeater_name}_100_{$sub_field_name}" is deleted and then each following row is updated "{$repeater_name}_101_{$sub_field_name}" becomes "{$repeater_name}_100_{$sub_field_name}", "{$repeater_name}_102_{$sub_field_name}" becomes "{$repeater_name}_101_{$sub_field_name}", etc… When all of the sub rows are updated ACF then updates the number of rows in the repeater.

Now lets say that your repeater has 5 sub fields, you can do this with any number of fields. The total number of DB queries that need to be done to update a repeater is

$total_queries = ($number_of_sub_fields * $number_of_rows + 1) * 2;

Repeaters have their uses, but they are not scalable. If you are going to have more than maybe a couple of dozen rows or you have a significant number of sub fields then a repeater is overall a bad choice to store the data. The same will happen with flexible content fields. When you have a large data set then a custom post type is generally a better idea. My personal opinion is that this should be stated in the documentation in big bold letters for both repeaters and flex fields.

There has been many topics here over the years on the subject of the slowness of repeaters with a large number of rows.

This will not change as long as ACF uses the 1 field = 1 query standard WP model for updating meta values.