Under special circumstances, a sequence of statements to create and drop Python libraries fails. For example, the following session statements attempt to create Python libraries lib1 and lib2:

CREATE LIBRARY lib1 AS :lib1_path DEPENDS :numpy_path LANGUAGE 'Python';
DROP LIBRARY lib1;
CREATE LIBRARY lib2 AS :lib2_path DEPENDS :sklearn_path LANGUAGE 'Python';

Here, lib1 is a Python library that imports module numpy, while lib2 imports module sklearn, which relies on numpy. After lib1 is dropped, the CREATE LIBRARY statement for lib2 fails.

Users can now control configuration parameter MaxDVROSPerContainer knob and set it to any value >1. The new formula is:

max(2, (MaxDVROSPerContainer+1)/2)

A two-level strata helps avoid excessive DVMergeouts: DVs with fewer deleted rows than (TBL.nrows/MaxDVROSPerStratum), where maxDVROSPerStratun is max(2, (MaxDVROSPerContainer+1)/2), are placed at stratum 0; if the number of these DVs exceeds MaxDVROSPerStratum, they are merged together. As before, larger DVs at stratum 1 are not merged.

Vertica was unable to optimize queries on v_internal tables, where equality predicates (with operator =) filtered on columns relname or nspname, in the following cases:

• The predicate specified expressions with embedded characters such as underscore (_) or percentage (%). For example:

  SELECT * FROM v_internal.vs_columns WHERE nspname = 'x_yz';
  

• The query contained multiple predicates separated by AND operators, and more than one predicate queried the same column, either nspname or relname. For example:

  SELECT * FROM v_internal.vs_columns WHERE nspname = 'xyz' AND nspname <> 'vs_internal';
  

In this case, Vertica was unable to optimize equality predicate nspname = 'xyz'.

In all these cases, the queries are now optimized as expected.

An internal memory error sometimes caused simple CASE statements of this format to fail:

CASE expression
WHEN comparand THEN result
...
[ ELSE result ]
END

This issue has been resolved.

Previously, when migrate_enterprise_to_eon found projections that were Inconsistent with cluster segmentation, it wrote to the migration log file an incorrect anchor table name; it also provided only one projection, _b0. This issue has been resolved: now the log file error log file lists the names of all tables with problematic projections. You can use these names as arguments to meta-function REBALANCE_TABLE.

A ROS of inactive partitions was excluded from mergeout if it was very large in relation to the size of other ROS's to be merged. Now, a large ROS container of inactive partitions is merged with smaller ROS containers when the following conditions are true:

• Total number of ROS containers for the projection is close to the threshold for ROS pushback.
• Total mergeout size does not exceed the limit for ROS container size.

If you created projections in earlier (pre-10.0.x) releases with pre-aggregated data (for example, LAPs and TopK projections) and the anchor tables were partitioned with a GROUP BY clause, their ROS containers are liable to be corrupted from various DML and ILM operations. In this case, you must rebuild the projections:

1. Identify problematic projections by running the meta-function REFRESH on the database.

2. Export the DDL of these projections with EXPORT_OBJECTS or EXPORT_TABLES.

3. Drop the projections, then recreate them as originally defined.

4. Run REFRESH. Vertica rebuilds the projections with new storage containers.

Setting configuration parameter CascadeResourcePoolAlwaysReplan = 1 occasionally caused problems when a timed-out query had already started producing results on the original resource pool. Now, if configuration parameter CascadeResourcePoolAlwaysReplan = 1, and a query times out on the original resource pool and must cascade to a secondary pool, the following behavior applies:

• The query has not started to produce results: the query cascades to the secondary resource pool and creates another query plan.

• The query already started to produce results: The query cascades to the secondary resource pool where CascadeResourcePoolAlwaysReplan is ignored, and query output continues.

When you add a column to a table with ALTER TABLE...ADD COLUMN, Vertica registers an AddDerivedColumnEvent, which it uses during node recovery to avoid rebuilding projections of that table. When you dropped a column from the same table with ALTER TABLE...DROP COLUMN, Vertica updated this event to indicate that the number of table columns changed. At the same time, it also checked if the dropped column was referenced as the default expression of another column in the table. If so, Vertica returned with an error and hint to advance the AHM before before executing the drop. Users who lacked privileges to advance the AHM were blocked from performing the drop operation.

This issue has been resolved: given the same conditions, dropping a column no longer depends on advancing the AHM. Instead, Vertica now sets the AddDerivedColumnEvent attribute number to InvalidAttrNumber. When the next recovery operation detects this setting, it rebuilds the affected projections.

A ROS of inactive partitions was excluded from mergeout if it was very large in relation to the size of other ROS's to be merged. Now, a large ROS container of inactive partitions is merged with smaller ROS containers when the following conditions are true:

• Total number of ROS containers for the projection is close to the threshold for ROS pushback.
• Total mergeout size does not exceed the limit for ROS container size.