You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -219,20 +211,8 @@ If you need to cancel a reindex job, use a `DELETE` call and specify the reindex
219
211
220
212
## Performance considerations
221
213
222
-
A reindex job can be quite performance intensive. The FHIR service offers throttling controls to help manage how a reindex job runs on your database.
223
-
224
-
> [!NOTE]
225
-
> It is not uncommon on large datasets for a reindex job to run for days.
226
-
227
-
Below is a table outlining the available parameters, defaults, and recommended ranges for controlling reindex job compute resources. You can use these parameters to either speed up the process (use more compute) or slow down the process (use less compute).
|`QueryDelayIntervalInMilliseconds`| The delay between each batch of resources being kicked off during the reindex job. A smaller number speeds up the job while a larger number slows it down. | 500 MS (.5 seconds) | 50 to 500000 |
232
-
|`MaximumResourcesPerQuery`| The maximum number of resources included in the batch to be reindexed. | 100 | 1-5000 |
233
-
|`MaximumConcurrency`| The number of batches done at a time. | 1 | 1-10 |
234
-
235
-
If you want to use any of the preceding parameters, you can pass them into the `Parameters` resource when you send the initial `POST` request to start a reindex job.
214
+
A reindex job can be quite performance intensive. The FHIR service offers throttling controls to help manage how a reindex job runs on your database. You can use `MaximumResourcesPerQuery` parameter to either speed up the process (use more compute) or slow down the process (use less compute). `MaximumResourcesPerQuery` parameter allows to set the maximum number of resources included in the batch to be reindexed. The default value is 100 and you can set value between 1-5000.
0 commit comments