|Functionality||After||Before||Result of changes|
|Working with DBMS.||Optimized performance of Oracle DBMS queries that include complex conditions for data access restrictions.||Insufficient performance of queries that include complex conditions for data access restrictions.||Improved performance of operations with data access restrictions in Oracle Database.|
|Applied objects.||Working with memory is optimized for some mechanisms.||Insufficient performance in certain scenarios.||Improved overall system performance in some scenarios.|
|Working with queries.||When executing a query, for all IN HIERARCHY conditions with the same parameter value a single temporary table per batch query is generated.||When executing a query, for IN HIERARCHY conditions with the same parameter value several temporary tables were generated.||Improved the performance of queries containing the same parameter values in several IN HIERARCHY operations.|
|Working with queries.||When executing a query, for all IN conditions with the same list of values a single temporary table per batch query (for storing the list) is used.||When executing a query, for IN conditions with the same list of values several temporary tables were generated, one for each condition.||Improved the performance of queries containing the same list of values in several IN operations.|
|Working with queries.||Improved performance of queries that include the IN HIERARCHY expression. Improved performance of queries that include performing data composition system operations on external data sources by using the IN GROUP and IN GROUP FROM THE LIST expressions.||Insufficient performance of query and report selections in some cases when hierarchy conditions were used.||Improved performance of query and report selections in some cases when hierarchy conditions are used.|
|Server cluster. Client application.||The amount of memory consumed by server working processes is significantly reduced. Reduced client application startup time. The effect is especially noticeable on configurations having large volumes of metadata.||Inefficient use of memory on configurations having large volumes of metadata.||Memory requirements for servers with configurations having large volumes of metadata are reduced.|
|Operating with DBMS.||For PostgreSQL and Oracle Database, optimized recording register records with update of account register totals. The optimization is achieved by introducing a new index. The performance increase takes effect after restructuring accounting registers and disabling the compatibility mode.||The data structure did not allow using the existing indexes at their full potential, which led to insufficient system efficiency.||Improved performance of operations with accounting registers in PostgreSQL and Oracle Database DBMS.|
|Operating with DBMS.||Improved performance of requests to main tables when Oracle Database is used.||Response time for some DBMS requests was sub-optimal.||Improved performance of database requests. This includes a significant increase in the speed of configuration updates that require infobase structure updates.|
|Operating with DBMS.||Optimized some accounting register-related DBMS requests. In particular, optimized requests that include filters by account.||Inefficient usage of DBMS capabilities.||Improved performance for "heavy" accounting register requests (such as, when creating accounting reports or performing month-end closing).|
|Operating with DBMS.||Optimized operations with temporary tables in Microsoft SQL Server, as well as operations with objects that use temporary tables: accumulation registers, accounting registers, sequences, and so on.||Insufficient performance in case of heavy usage of temporary tables.||Improved performance in case of heavy usage of temporary tables in Microsoft SQL Server.|
|Web client.||Faster start of the web client on slow connections.||A large amount of service information was obtained during the start of the web client.||Faster start of the web client on slow connections.|
|Operating with DBMS.||Improved performance of operations with Microsoft SQL Server DBMS in the following cases:
||Inefficient usage of DBMS capabilities.||Improved performance of operations with infobases that use Microsoft SQL Server DBMS.|
|Accounting registers.||Improved performance of accounting register operations in the following cases:
The performance increase takes effect after infobase restructuring.
|Insufficient performance of accounting register operations in certain use cases.||Improved performance of operations with accounting registers containing a large amount of data.|
|Operating with DBMS.||The performance of operations with PostgreSQL is improved by changing the index structure. The optimization applies both to new infobases and to existing ones (after restructuring their databases).||Cluster indexes were not used in PostgreSQL operations; regular indexes were created instead.||Faster execution of PostgreSQL operations.|
|Operating with DBMS.||You can use separate table spaces for indexes (the v81c_index space) and for data (the v81c_data space) in PostgreSQL.
Table spaces are not created automatically; a database administrator creates them. If no additional table spaces are created, the default table space (pg_default) is used.
|Using a single table space might decrease the performance (due to storage medium overload or performance limitations).||Balancing system performance by recording table spaces to multiple storage media in PostgreSQL.|
|Web client.||Faster opening of the following forms in the web client:
||Delays when opening forms in the web client.||Faster form opening, which improves user experience.|
|Working with queries.||Improved performance retrieving a selection by group (with a large number of records) from a result of a query containing a TOTALS clause.||Insufficient performance when retrieving a selection by group from a result of a query that contains totals.||Improved performance when processing results of queries that contain totals.|
|Server cluster.||Improved server performance and scalability when processing reference data types.||Insufficient server performance when processing reference data types.||Improved server performance when processing reference data types.|
|Operating with DBMS.||Temporary tables containing data of unrestricted length are temporary in IBM DB2 version 8.7 and later.||For data of unrestricted length, permanent tables were created and then deleted after use.||System tables cannot get locked. Improved user experience in case when a large number of users are working simultaneously.|
|Operating with DBMS.||Certain operations with IBM DB2 are optimized.||Insufficient usage of IBM DB2 capabilities.||Faster execution of IBM DB2 operations.|
|Operating with DBMS. Accounting registers.||Faster processing of accounting register data during database configuration update in the client/server infobase mode.||Insufficient performance when reconfiguring accounting registers.||Faster processing of accounting register data during their reconfiguration.|
|Information registers.||Totals are implemented for periodic information registers. They are intended for retrieving first and last slices, provided that the following conditions are met:
Properties EnableTotalsSliceFirst and EnableTotalsSliceLast are implemented for information registers.
Methods RecalcTotals(), SetTotalsUsing(), and GetTotalsUsing() are implemented for information register managers.
Access right TotalsControl is implemented for information registers. The Verify and Repair action in Designer includes recalculation of first and last slices if the Recalculating totals option is enabled in the Verifications and modes list and using totals is enabled for the register.
|Each slice retrieval resulted in execution of a query to the main register table, with calculation of resource values.||Faster retrieval of first and last slices for the first and the last (current) moments of time.|
|Developing tools.||Optimized memory usage in the following cases:
This change is not implemented in 8.2.16 compatibility mode.
|In some cases working with configurations that are supported by vendor configurations of large size was impossible.||Reduced RAM usage when working with vendor configurations of large size.|