Update arangosearch-views-reference.md

site/content/3.10/develop/foxx-microservices/guides/working-with-files.md

@@ -61,11 +61,11 @@ the filesystem from within a service:
   may therefore cause race conditions and **result in corrupted data**.
 
 - Writing to files outside the service folder introduces external state. In
-  a cluster this will result in Coordinators no longer being interchangeable.
+  a cluster, this results in Coordinators no longer being interchangeable.
 
 - Writing to files during setup is unreliable because the setup script may
-  be executed several times or not at all. In a cluster the setup script
-  will only be executed on a single Coordinator.
+  be executed several times or not at all. In a cluster, the setup script
+  is only executed on a single Coordinator.
 
 Therefore it is almost always a better option to store files using a
 specialized, external file storage service
@@ -77,13 +77,13 @@ ArangoDB documents by using a separate collection.
 {{< danger >}}
 Due to the way ArangoDB stores documents internally, you should not store
 file contents alongside other attributes that might be updated independently.
-Additionally, large file sizes will impact performance for operations
+Additionally, large file sizes impact performance for operations
 involving the document and may affect overall database performance.
 {{< /danger >}}
 
 {{< warning >}}
 In production, you should avoid storing any files in ArangoDB or handling file
-uploads in Foxx. The following example will work for moderate amounts of small
+uploads in Foxx. The following example works for moderate amounts of small
 files but is not recommended for large files or frequent uploads or
 modifications.
 {{< /warning >}}

site/content/3.10/develop/http-api/indexes/inverted.md

@@ -472,10 +472,10 @@ paths:
                     Wait at least this many commits between removing unused files in the
                     ArangoSearch data directory (default: 2, to disable use: 0).
                     For the case where the consolidation policies merge segments often (i.e. a lot
-                    of commit+consolidate), a lower value will cause a lot of disk space to be
+                    of commit+consolidate), a lower value causes a lot of disk space to be
                     wasted.
                     For the case where the consolidation policies rarely merge segments (i.e. few
-                    inserts/deletes), a higher value will impact performance without any added
+                    inserts/deletes), a higher value impacts performance without any added
                     benefits.
 
                     _Background:_
@@ -491,12 +491,11 @@ paths:
                     Wait at least this many milliseconds between committing inverted index data store
                     changes and making documents visible to queries (default: 1000, to disable
                     use: 0).
-                    For the case where there are a lot of inserts/updates, a lower value, until
-                    commit, will cause the index not to account for them and memory usage would
-                    continue to grow.
-                    For the case where there are a few inserts/updates, a higher value will impact
-                    performance and waste disk space for each commit call without any added
-                    benefits.
+                    For the case where there are a lot of inserts/updates, a higher value causes the
+                    index not to account for them and memory usage continues to grow until the commit.
+                    A lower value impacts performance, including the case where there are no or only a
+                    few inserts/updates because of synchronous locking, and it wastes disk space for
+                    each commit call.
 
                     _Background:_
                       For data retrieval, ArangoSearch follows the concept of
@@ -518,7 +517,7 @@ paths:
                     For the case where there are a lot of data modification operations, a higher
                     value could potentially have the data store consume more space and file handles.
                     For the case where there are a few data modification operations, a lower value
-                    will impact performance due to no segment candidates available for
+                    impacts performance due to no segment candidates being available for
                     consolidation.
 
                     _Background:_
@@ -536,8 +535,8 @@ paths:
                     _Background:_
                       With each ArangoDB transaction that inserts documents, one or more
                       ArangoSearch-internal segments get created.
-                      Similarly, for removed documents the segments that contain such documents
-                      will have these documents marked as 'deleted'.
+                      Similarly, for removed documents, the segments that contain such documents
+                      have these documents marked as 'deleted'.
                       Over time, this approach causes a lot of small and sparse segments to be
                       created.
                       A "consolidation" operation selects one or more segments and copies all of
@@ -594,7 +593,7 @@ paths:
                   description: |
                     Maximum memory byte size per writer (segment) before a writer (segment) flush
                     is triggered. `0` value turns off this limit for any writer (buffer) and data
-                    will be flushed periodically based on the value defined for the flush thread
+                    is flushed periodically based on the value defined for the flush thread
                     (ArangoDB server startup option). `0` value should be used carefully due to
                     high potential memory consumption
                     (default: 33554432, use 0 to disable)