IBM has just released Informix 12.10.xC3 this last Friday (March 14). The packages were available on FixCentral since the beginning of the week, but the documentation was updated only on Friday. As usual for a few years each fixpack contains small improvements and a few gems. This one is no exception. Here is the list directly from the documentation with a few comments added:

Migration
Server changes
JSON compatibility pre- and post-migration requirements
New reversion requirements
These are "just" some new parameters and things we should consider when upgrading or downgrading. I will refer to some of them later
Installation
Server configuration
Automatically configure the server during installation
If we choose to configure a server during installation, resources are adjusted automatically and the JSON listener is started
Administration
Autonomics
Automatic resource tuning for performance
Some of the new parameters mentioned above are relevant to this. As an example we can have a dynamic buffer pool, let the server create more logical logs, let it adjust the physical log size and reconfigure the CPU and AIO VPs. This is another great step in the autonomic chapter.
Automatic location and fragmentation
Another major change. If you prefer (set AUTOLOCATE parameter) the new tables are automatically created in a set of dbspaces, and fragmented in round-robin. If the tables grow, new fragments are automatically created. No more "no more pages" errors. For the old timer DBA (like me) this sounds tricky... but times do change and we must keep up. You're not forced to use this, but it will probably fit some environments
Performance
Control the size of private memory caches
In previous fixpacks the private memory caches used by each CPU VP changed to dynamic. Now you have the option to make them static
Virtual shared memory segment size doubling
Like we do in the extents for the tables, each 16 memory segments that we allocate we double their size. The idea is to keep their number low. But again, for old timers, 16 is already a very large number. We usually try to keep them below 5 (?). But this also means we can have them lower initially because we know that if the server grows to much, it will adapt.
Connectivity
Retrying connections
As we've seen in 11.70.xC8, we can now define INFORMIXCONTIME and INFORMIXCONRETRY as $ONCONFIG parameters and by using the SET ENVIRONMENT statement.
This seems nice but to be honest I was not really getting it (I should have noticed it when I wrote about 11.70.xC8). My confusion is caused by the fact that I usually use these settings to avoid spending too much time trying to connect to a dead or unreachable server. But if we cannot reach the server how would having these settings on the server side help?!
Because this is to be applied on distributed queries and for that it makes sense.
Application development
JSON compatibility
Use the MongoDB API to access relational data
You can access relational tables with the MongoDB API methods
Improved JSON compatibility
New MongoDB API methods are supported like findAndModify() and some authentication related operations
Foreign-key constraints
Temporarily prevent constraint validation
As in 11.70.xC8 this introduces the ability to use NOVALIDATE on foreign-key constraints creation to speed up the process
Faster creation of foreign-key constraints
As in 11.70.xC8, real creation of foreign keys can take better advantage of existing indexes
Compatibility
Find the quarter of the calendar year for dates
Implementation of the QUARTER() SQL function. A request from the market for better integration with 3rd party BI tools
High-availability clusters and Enterprise Replication
Connection Manager
Improvements to Connection Manager
Introduction of two new redirection policies: ROUNDROBIN and SECAPPLYBACKLOG
Monitoring
View log-staging information on RS secondary servers
Get information about log staging information in RSS servers where the DELAY APPLY functionality is in use
Configuration
Easier configuration and cloning of a server for replication
Easily configure and start Enterprise Replication
Sharding
Shard data across Enterprise Replication servers
Shard is a term that refers to the distribution of a single object across a number of nodes. The purpose is a bit like "divide and conqueror". By distributing records, documents or rows we make them more manageable in each node and gain performance by having more hardware dealing with our data. Informix can now "shard" relational tables and collections (JSON) across instances in an Enterprise Replication domain
Spatial data
Enhancements for handling spatial data
More spatial reference systems and the ability to calculate area and distance for data based on the round-Earth model.
Informix spatial data types now conform to the OpenGIS Simple Features Specification for SQL Revision 1.1 and the ISO/IEC 13249-3 SQL/MM Part 3: Spatial. The Informix spatial solution is based on the ESRI SDE 10.2 Shape and PE libraries.
Time series data
Storage
Efficient storage for hertz and numeric time series data
Timeseries can store a series of sub-second values in a packed element (up to 4KB)
Containers
Control the destroy behavior for rolling window containers
Limit the number of windows of a rolling window container that can be destroyed in a single operation
Monitor groups of containers with wildcard characters
Several monitorization functions now allow wildcards in the container name
Faster queries
Faster queries by running time series routines in parallel
Functions that can be used in WHERE clause of a SELECT statement now can take advantage of PDQ PRIORITY (parallelism) if the tables are fragmented
Faster queries with IN conditions through virtual tables
Optimization for queries with IN conditions
Warehousing
Additional types of data
Accelerate warehouse queries in-memory using data from multiple sources
Synonyms and views can now reference tables in different databases, tables in databases of the same Informix instance, or tables in a different Informix instance. This work for JSON data also


Beyond the very light review above, I'd like to highlight a few points:

Dynamic buffer pool. Although currently it can "only" be set to self tune (it will grow within specified limits if the read cache hits are lower than a threshold we define), this will be an historical step. I remember that while explaining the dynamic parameters we were introducing, I sometimes mentioned that "some like BUFFERPOOL will possibly never be dynamic".... Well, I must rethink that statement. Although currently it's not dynamic, if it can automatically adjust the buffers, I imagine we'll be able to do the same in the future (by using onmode -wm/wf for example)
You may noticed that some features introduced in xC3 of version 12.10 were already introduced in xC8 of version 11.70. This happens because some features are being developed across more than one code line, and they appear first in version N-1 or N depending on the release schedule and calendar. Nothing to do with marketing... If the code change is feasible in more than one version we give it to customers. We don't force them to upgrade to get any new stuff. How many vendors incorporate new features in previous product versions?!
Continuous improvements in many distinctive areas: Timeseries, JSON, IWA.

наконец-то появилась функция получения плана SQL-запроса без использования хитромудрых способов: