你好Sun Oct 26 15:46:35 CST 2025 postgres

David Rowley Fix incorrect logic for caching ResultRelInfos for triggers

When dealing with ResultRelInfos for partitions, there are cases where
there are mixed requirements for the ri_RootResultRelInfo. There are
cases when the partition itself requires a NULL ri_RootResultRelInfo and
in the same query, the same partition may require a ResultRelInfo with
its parent set in ri_RootResultRelInfo. This could cause the column
mapping between the partitioned table and the partition not to be done
which could result in crashes if the column attnums didn't match
exactly.

The fix is simple. We now check that the ri_RootResultRelInfo matches
what the caller passed to ExecGetTriggerResultRel() and only return a
cached ResultRelInfo when the ri_RootResultRelInfo matches what the
caller wants, otherwise we'll make a new one.

Author: David Rowley [email protected]
Author: Amit Langote [email protected]
Reported-by: Dmitry Fomin [email protected]
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 15 2025-10-25T21:59:50Z

Proxy download:

curl -#Lo /opt/pg.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251026_1544_pg/pg-indiff-centos7-x86_64-20251026_1543.xz"

Direct download:

curl -#Lo /opt/pg.zip "https://github.com/indiff/indiff/releases/download/20251026_1544_pg/pg-indiff-centos7-x86_64-20251026_1543.xz"

你好Sat Oct 25 21:21:52 CST 2025 percona

Przemyslaw Skibinski PS-10247 [8.0]: Move default MTR test lists from Jenkins job to PS code

Introduce mysql-test/suites-groups.sh with set_suites() function
which sets WORKER_x_MTR_SUITES for x=1..8 (different sets for Debug,
RelWithDebInfo, and Valgrind).

Jenkins will try to download mysql-test/suites-groups.sh and call
set_suites() function before it will use the default split defined in
https://github.com/Percona-Lab/ps-build/blob/8.0/jenkins/suites-groups.sh 2025-10-21T18:00:21Z

mariadb

Dave Gosselin MDEV-36125 [NO_]INDEX_MERGE Hint

Introduces NO_INDEX_MERGE and INDEX_MERGE, which control whether or
not index merge strategies are used during query optimization. Here
is an example query from the tests:

SET optimizer_switch='index_merge_intersection=off';
EXPLAIN SELECT /*+ INDEX_MERGE(t1 f4, f2) / COUNT() FROM t1
WHERE f4 = 'h' AND f2 = 2;

with the hint in place, the query plan will employ the index_merge
intersect strategy (abbreviated EXPLAIN output):

type Extra
index_merge Using intersect(f2,f4); Using where; Using index

The presence of the [NO_]INDEX_MERGE hint overrides the optimizer's
choice of keys during the index merge optimization. As we see in
the above example, keys f2 and f4 and given and the optimizer will
consider only those keys for this query.

When the hint is given without any particular keys, as in
INDEX_MERGE(table), then all keys are considered. In this case, the
cheapest index merge among the keys should be used. When
NO_INDEX_MERGE(table) is given, then index merge is disabled for
that table.

When the hint is given with one or more keys, then only those keys
are considered. In the case of NO_INDEX_MERGE, those keys are
excluded. This can lead to no merged indexes at all, because
there may not be sufficient row-ordered read columns available for
consideration.

The index merge strategies of intersection, union, and sort union
cannot themselves be directly controlled via the hints. In combination
with the optimizer switches for the same, the strategy may be
indirectly controlled but this is not guaranteed.

When the hint directs the optimizer such that insufficient ROR scans
are available, thus leading to a situation where the INDEX_MERGE hint
cannot be honored, the server will emit a warning to that effect.

In the hints module (opt_hints*{cc,h}), this commit adds some
index merge-specific functionality to make interpreting hint state
at callsites in the optimizer cleaner and more intuitive.
Particularly, we add a bit field to the table hints class which
indicates the keys that are marked by an [NO_]INDEX_MERGE hint, if
present. A new function, index_merge_hint (and associated new
helper functions) relies on this field when interpreting index merge
hint state for the optimizer.

If there are no index merges available prior to attemping to find
a suitable union/sort union, then the optimizer will not attempt
it. This change results in optimizer trace output which does not
include the 'analyzing_index_merge_union' block when there are no
merges.

Parts of this implementation based on MySQL commit
ebcb981807e3d91a64782e89d48e1a25622eafea 2025-05-02T18:38:46Z

Proxy download:

curl -#Lo /opt/percona80.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251025_2121_mysql/percona80-centos7-x86_64-20251025_1842.xz"

curl -#Lo /opt/mariadb.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251025_2121_mysql/mariadb-centos7-x86_64-20251025_1714.xz"

curl -#Lo /opt/percona80.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251025_2121_mysql/percona80-ubuntu-x86_64-20251025_0814.xz"

curl -#Lo /opt/fbmysql.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251025_2121_mysql/fbmysql-centos7-x86_64-20251025_2104.xz"

curl -#Lo /opt/omysql.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251025_2121_mysql/omysql-centos7-x86_64-20251025_2116.xz"

Direct download:

curl -#Lo /opt/percona80.zip "https://github.com/indiff/indiff/releases/download/20251025_2121_mysql/percona80-centos7-x86_64-20251025_1842.xz"

curl -#Lo /opt/mariadb.zip "https://github.com/indiff/indiff/releases/download/20251025_2121_mysql/mariadb-centos7-x86_64-20251025_1714.xz"

curl -#Lo /opt/percona80.zip "https://github.com/indiff/indiff/releases/download/20251025_2121_mysql/percona80-ubuntu-x86_64-20251025_0814.xz"

你好Sat Oct 25 15:46:18 CST 2025 postgres

Michael Paquier pg_rewind: Skip copy of WAL segments generated before point of divergence

This commit makes the way WAL segments are handled from the source to
the target server slightly smarter: the copy of the WAL segments is now
skipped if these have been created before the point where source and
target have diverged (the WAL segment where the point of divergence
exists is still copied), because we know that such segments exist on
both the target and source. Note that the on-disk size of the WAL
segments on the source and target need to match. Hence, only the
segments generated after the point of divergence are now copied. A
segment existing on the source but not the target is copied.

Previously, all the WAL segments were just copied in full. This change
can make the rewind operation cheaper in some configurations, especially
for setups where some WAL retention causes many segments to remain on
the source server even after the promotion of a standby used as source
to rewind a previous primary.

A TAP test is added to track these new behaviors. The file map printed
with --debug now includes all the information related to WAL segments,
to be able to track if these are copied or skipped, and the test relies
on the debug output generated.

Author: John Hsu [email protected]
Author: Justin Kwan [email protected]
Reviewed-by: Robert Haas [email protected]
Reviewed-by: Alexander Korotkov [email protected]
Reviewed-by: Japin Li [email protected]
Reviewed-by: Michael Paquier [email protected]
Reviewed-by: Srinath Reddy Sadipiralla [email protected]
Discussion: https://postgr.es/m/[email protected] 2025-10-25T00:07:31Z

Proxy download:

curl -#Lo /opt/pg.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251025_1544_pg/pg-indiff-centos7-x86_64-20251025_1543.xz"

Direct download:

curl -#Lo /opt/pg.zip "https://github.com/indiff/indiff/releases/download/20251025_1544_pg/pg-indiff-centos7-x86_64-20251025_1543.xz"

你好Fri Oct 24 15:49:37 CST 2025 postgres

Fujii Masao psql: Improve tab completion for large objects.

This commit enhances psql's tab completion support for large objects:

• Completes \lo_export with a file name
• Completes GRANT/REVOKE ... LARGE with OBJECT
• Completes ALTER DEFAULT PRIVILEGES GRANT/REVOKE ... LARGE with OBJECTS

Author: Dagfinn Ilmari Mannsåker [email protected]
Co-authored-by: Fujii Masao [email protected]
Reviewed-by: Chao Li [email protected]
Discussion: https://postgr.es/m/[email protected] 2025-10-24T05:30:05Z

Proxy download:

curl -#Lo /opt/pg.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251024_1547_pg/pg-indiff-centos7-x86_64-20251024_1546.xz"

Direct download:

curl -#Lo /opt/pg.zip "https://github.com/indiff/indiff/releases/download/20251024_1547_pg/pg-indiff-centos7-x86_64-20251024_1546.xz"

你好Thu Oct 23 15:50:11 CST 2025 postgres

Michael Paquier pg_rewind: Extend code detecting relation files to work with WAL files

isRelDataFile() is renamed to getFileContentType(), extended so as it
becomes able to detect more file patterns than only relation files. The
new file name pattern that can be detected is WAL files.

This refactoring has been suggested by Robert Haas. This will be used
in a follow-up patch where we are looking at improving how WAL files are
processed by pg_rewind. As of this change, WAL files are still handled
the same way as previously, always copied from the source to the target
server.

Extracted from a larger patch by the same authors.

Author: John Hsu [email protected]
Author: Justin Kwan [email protected]
Reviewed-by: Japin Li [email protected]
Reviewed-by: Srinath Reddy Sadipiralla [email protected]
Discussion: https://postgr.es/m/[email protected] 2025-10-23T06:57:46Z

Proxy download:

curl -#Lo /opt/pg.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251023_1548_pg/pg-indiff-centos7-x86_64-20251023_1547.xz"

Direct download:

curl -#Lo /opt/pg.zip "https://github.com/indiff/indiff/releases/download/20251023_1548_pg/pg-indiff-centos7-x86_64-20251023_1547.xz"

你好Wed Oct 22 21:31:38 CST 2025 percona

Varun Nagaraju PS-9220 [8.0]: Error during slow Query Log Rotation

https://perconadev.atlassian.net/browse/PS-9220

When multiple client threads are connected to the server, there can be
cases where the slow log purging after rotation attempt to delete the
older slow log files which don't exist anymore. In some of such cases,
the error returned by my_errno() after the unlink() method call was
inaccuarte causing error messages to be printed in the server error
log. So, my_errno() is replcaed with errno for accurate error returned. 2025-10-16T11:32:14Z

mariadb

Dave Gosselin MDEV-36125 [NO_]INDEX_MERGE Hint

Introduces NO_INDEX_MERGE and INDEX_MERGE, which control whether or
not index merge strategies are used during query optimization. Here
is an example query from the tests:

SET optimizer_switch='index_merge_intersection=off';
EXPLAIN SELECT /*+ INDEX_MERGE(t1 f4, f2) / COUNT() FROM t1
WHERE f4 = 'h' AND f2 = 2;

with the hint in place, the query plan will employ the index_merge
intersect strategy (abbreviated EXPLAIN output):

type Extra
index_merge Using intersect(f2,f4); Using where; Using index

The presence of the [NO_]INDEX_MERGE hint overrides the optimizer's
choice of keys during the index merge optimization. As we see in
the above example, keys f2 and f4 and given and the optimizer will
consider only those keys for this query.

When the hint is given without any particular keys, as in
INDEX_MERGE(table), then all keys are considered. In this case, the
cheapest index merge among the keys should be used. When
NO_INDEX_MERGE(table) is given, then index merge is disabled for
that table.

When the hint is given with one or more keys, then only those keys
are considered. In the case of NO_INDEX_MERGE, those keys are
excluded. This can lead to no merged indexes at all, because
there may not be sufficient row-ordered read columns available for
consideration.

The index merge strategies of intersection, union, and sort union
cannot themselves be directly controlled via the hints. In combination
with the optimizer switches for the same, the strategy may be
indirectly controlled but this is not guaranteed.

When the hint directs the optimizer such that insufficient ROR scans
are available, thus leading to a situation where the INDEX_MERGE hint
cannot be honored, the server will emit a warning to that effect.

In the hints module (opt_hints*{cc,h}), this commit adds some
index merge-specific functionality to make interpreting hint state
at callsites in the optimizer cleaner and more intuitive.
Particularly, we add a bit field to the table hints class which
indicates the keys that are marked by an [NO_]INDEX_MERGE hint, if
present. A new function, index_merge_hint (and associated new
helper functions) relies on this field when interpreting index merge
hint state for the optimizer.

If there are no index merges available prior to attemping to find
a suitable union/sort union, then the optimizer will not attempt
it. This change results in optimizer trace output which does not
include the 'analyzing_index_merge_union' block when there are no
merges.

Parts of this implementation based on MySQL commit
ebcb981807e3d91a64782e89d48e1a25622eafea 2025-05-02T18:38:46Z

Proxy download:

curl -#Lo /opt/percona80.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251022_2122_mysql/percona80-centos7-x86_64-20251022_1845.xz"

curl -#Lo /opt/mariadb.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251022_2122_mysql/mariadb-centos7-x86_64-20251022_1717.xz"

curl -#Lo /opt/percona80.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251022_2122_mysql/percona80-ubuntu-x86_64-20251022_0819.xz"

curl -#Lo /opt/fbmysql.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251022_2122_mysql/fbmysql-centos7-x86_64-20251022_2118.xz"

curl -#Lo /opt/omysql.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251022_2122_mysql/omysql-centos7-x86_64-20251022_2117.xz"

Direct download:

curl -#Lo /opt/percona80.zip "https://github.com/indiff/indiff/releases/download/20251022_2122_mysql/percona80-centos7-x86_64-20251022_1845.xz"

curl -#Lo /opt/mariadb.zip "https://github.com/indiff/indiff/releases/download/20251022_2122_mysql/mariadb-centos7-x86_64-20251022_1717.xz"

curl -#Lo /opt/percona80.zip "https://github.com/indiff/indiff/releases/download/20251022_2122_mysql/percona80-ubuntu-x86_64-20251022_0819.xz"

你好Wed Oct 22 15:47:24 CST 2025 postgres

Tatsuo Ishii Fix multi WinGetFuncArgInFrame/Partition calls with IGNORE NULLS.

Previously it was mistakenly assumed that there's only one window
function argument which needs to be processed by WinGetFuncArgInFrame
or WinGetFuncArgInPartition when IGNORE NULLS option is specified. To
eliminate the limitation, WindowObject->notnull_info is modified from
"uint8 *" to "uint8 **" so that WindowObject->notnull_info could store
pointers to "uint8 *" which holds NOT NULL info corresponding to each
window function argument. Moreover, WindowObject->num_notnull_info is
changed from "int" to "int64 *" so that WindowObject->num_notnull_info
could store the number of NOT NULL info corresponding to each function
argument. Memories for these data structures will be allocated when
WinGetFuncArgInFrame or WinGetFuncArgInPartition is called. Thus no
memory except the pointers is allocated for function arguments which
do not call these functions

Also fix the set mark position logic in WinGetFuncArgInPartition to
not raise a "cannot fetch row before WindowObject's mark position"
error in IGNORE NULLS case.

Reported-by: Tom Lane [email protected]
Author: Tatsuo Ishii [email protected]
Discussion: https://postgr.es/m/2952409.1760023154%40sss.pgh.pa.us 2025-10-22T03:06:33Z

Proxy download:

curl -#Lo /opt/pg.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251022_1546_pg/pg-indiff-centos7-x86_64-20251022_1545.xz"

Direct download:

curl -#Lo /opt/pg.zip "https://github.com/indiff/indiff/releases/download/20251022_1546_pg/pg-indiff-centos7-x86_64-20251022_1545.xz"

你好Tue Oct 21 15:51:38 CST 2025 postgres

David Rowley Fix BRIN 32-bit counter wrap issue with huge tables

A BlockNumber (32-bit) might not be large enough to add bo_pagesPerRange
to when the table contains close to 2^32 pages. At worst, this could
result in a cancellable infinite loop during the BRIN index scan with
power-of-2 pagesPerRange, and slow (inefficient) BRIN index scans and
scanning of unneeded heap blocks for non power-of-2 pagesPerRange.

Backpatch to all supported versions.

Author: sunil s [email protected]
Reviewed-by: David Rowley [email protected]
Reviewed-by: Michael Paquier [email protected]
Discussion: https://postgr.es/m/CAOG6S4-tGksTQhVzJM19NzLYAHusXsK2HmADPZzGQcfZABsvpA@mail.gmail.com
Backpatch-through: 13 2025-10-21T07:46:14Z

Proxy download:

curl -#Lo /opt/pg.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251021_1548_pg/pg-indiff-centos7-x86_64-20251021_1547.xz"

Direct download:

curl -#Lo /opt/pg.zip "https://github.com/indiff/indiff/releases/download/20251021_1548_pg/pg-indiff-centos7-x86_64-20251021_1547.xz"

你好Mon Oct 20 16:01:39 CST 2025 postgres

Fujii Masao pg_dump: Remove unnecessary code for security labels on extensions.

Commit d9572c4e3b4 added extension support and made pg_dump attempt to
dump security labels on extensions. However, security labels on extensions
are not actually supported, so this code was unnecessary.

This commit removes it.

Suggested-by: Jian He [email protected]
Author: Fujii Masao [email protected]
Reviewed-by: Jian He [email protected]
Discussion: https://postgr.es/m/CACJufxF8=z0v=888NKKEoTHQ+Jc4EXutFi91BF0fFjgFsZT6JQ@mail.gmail.com 2025-10-20T02:44:11Z

Proxy download:

curl -#Lo /opt/pg.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251020_1601_pg/pg-indiff-centos7-x86_64-20251020_1600.xz"

Direct download:

curl -#Lo /opt/pg.zip "https://github.com/indiff/indiff/releases/download/20251020_1601_pg/pg-indiff-centos7-x86_64-20251020_1600.xz"

你好Sun Oct 19 21:20:54 CST 2025 percona

Satya Bodapati PS-9837 [8.0]: Assertion failure !cursor->index->is_committed()` during DELETE + INSERT load

https://perconadev.atlassian.net/browse/PS-9837

Background:

The assertion failure means, a secondary index record that is expected to be delete-marked
is NOT delete-marked (ie, a normal record). This cannot happen for regular secondary indexes.
Only exemption given is indexes being built (Online ALTER).

The pre-conditions:

1. Compressed tables only (ROW_FORMAT=COMPRESSED)
2. many non-unique secondary indexes
3. Change-buffering enabled (to all)
4. IO bound workload to force change-buffering

Threads involved:

1. Purge thread that is bit delayed to ensure DELETE-MARKED records are present
2. LRU thread that does eviction of uncompressed frames of compressed pages. Eviction of pages
   from unzip_LRU
3. DELETE statement that does change-buffering on page. The same page is being evicted by LRU thread
   unzip_LRU eviction
4. A new insert that re-inserts the just deleted record.

Lets check the steps to the assertion failure. Lets use this table for discussion
create table t1
(
id int primary key,
value text not null,
uid int not null,
key k1(uid)
) engine=innodb ROW_FORMAT=COMPRESSED;

insert into t1 values (2, 'two value', 102);

This inserts a record (2, 'two value, 102) in clustered index and (102,2) in secondary index k1.
Lets call this secondary index page P1.

This page P1 is a compressed page and whenever this page is accessed by SELECTs, the page has uncompressed part
aka frame.

When a compressed page is read from disk. it doesn't have the uncompressed frame yet. After decompression (see
zip_page_handler), the page will have block->frame and the compressed part is in block->zip.data.
The page has also access_time set after decompression. The page is also in unzip_LRU. This LRU is a list of pages
that have both compressed and uncompressed frames.

On LRU pressure, there is logic to evict only the uncompressed part and keep the compressed part in the form of zip->data
(in bpage_t). buf_free_from_unzip_LRU_list_batch().

Step 1:

DELETE FROM t1 WHERE id = 2;

This query will delete-mark record in clustered index and secondary index records. When the secondary index record
is about be delete-marked on page P1, at the same moment, LRU eviction thread does uncompressed frame evictions from
unzip_LRU.

The eviction process is as follows:

1. we create a copy of bpage with compressed-frame only. During the copy the access_time is copied from the old block
   to the compressed-only bpage.
2. The current block which has both uncompressed and compressed frames is freed. buf_LRU_free_page()
3. buf_LRU_block_remove_hashed() in buf_LRU_free_page() releases page_hash and block mutex
4. Later we reacquire page_hash and block_mutex and again insert the compressed frame into the page_hash

Now there is teeny-tiny window between Step 3 & Step 4. At this window, if someone asks if a page is in the BP (buffer-pool), the answer is NO. Enter the DELETE statement into our discussion

when DELETE searches the record to be deleted on secondary index, the
page P1 will be looked if it is in BP, And remember the window above
between steps 3 & 4? if it so happens that the DELETE connection threads
asks if this page P1 is in BP, the answer is NO and it proceeds to
change-buffer the DELETE-marking. The record doesn't have DELETE-MARK
flag until the change buffer is merged.

Step 2:

A SELECT that access the secondary index page P1. As part of SELECT, it would see that the page is in BP but only has compressed data. ie the block state is BUF_BLOCK_ZIP_PAGE/BUF_BLOCK_ZIP_DIRTY. zip_page_handler() decompresses the compressed page and transform it to a regular page (both uncompressed and compressed parts are present).

In this, ibuf_merge_or_delete_for_page() is skipped if page already has
"access_time" set. From the eviction process above, we see that the
acess_time is copied from uncompressed block to compressed block
(bpage). This "Skipping of change-buffer merge" is the root cause
of the current bug.

Step 3:

Re-insertion of the just deleted record.

INSERT INTO t1 VALUES (2, 'two value', 102);

This will insert the record into clustered index and then proceeds to insert into secondary index. It finds that exact record is found. The cursor search leads the record (102,2). Then it sees that is exact match and expect to do the insert by "modify". Meaning, it has to just undelete-mark the record.

Since the change-buffer merge was skipped, the apply of DELETE-MARKING to the record is skipped. So the record is in "Normal" state. This is unexpected. We cannot find a record that is NOT in DELETE-MARKED. This is becuase we the clustered index already guaranteed that record was not present and such "insert by modify" always requires the record tbe DELETE-MARKED.

Since the record is in NORMAL state, the assertion fails!

Analysis:

When the compressed-page is read from disk, it is typically not
decompressed immediately. Its access_time is 0. A SELECT on the page
forces it to be decompressed. Since the page access time is zero, it is
considered firt transition to uncompressed and the change buffer merge is attempted.

But when the page transitioned from un-compressed to compressed during
LRU uncompressed-only eviction of compressed pages, the page access_time is not reset and the page is immediately in BP again.

A later reads/SELECTs decompress the page again but the difference is
the change-buffer merge is skipped because it is considered the page is already accessed.

Fix:

Although removing page hash release and acquire in buf_LRU_free_page() is the most ideal solution, it has latch ordering complications.

Luckily a simpler alternative exist. We can simply attempt to ibuf
merge always if block state is BUF_BLOCK_ZIP_PAGE or BUF_BLOCK_ZIP_DIRTY

All transitions to states of BUF_BLOCK_ZIP_PAGE or ZIP_DIRTY have possibility
of ibuf entries on the page.

unzip_LRU uncompressed frame evictions create a small window for ibuf
entries on the page. buf_LRU_block_remove_hashed() in buf_LRU_free_page()
releases page hash lock and block mutex. Before they are re-acquired, ibuf
is possible on the page

DISK->ZIP_PAGE : ibuf entry should be applied (page was out of BP)
FILE_PAGE->ZIP_PAGE: caused by unzip_LRU eviction
ZIP_PAGE -> ZIP_DIRTY: page dirty on unzip LRU eviction
ZIP_DIRTY->ZIP_PAGE: a dirty page (previously on unzip_LRU) is flushed. 2025-10-06T12:03:47Z

mariadb

Dave Gosselin MDEV-36125 [NO_]INDEX_MERGE Hint

Introduces NO_INDEX_MERGE and INDEX_MERGE, which control whether or
not index merge strategies are used during query optimization. Here
is an example query from the tests:

SET optimizer_switch='index_merge_intersection=off';
EXPLAIN SELECT /*+ INDEX_MERGE(t1 f4, f2) / COUNT() FROM t1
WHERE f4 = 'h' AND f2 = 2;

with the hint in place, the query plan will employ the index_merge
intersect strategy (abbreviated EXPLAIN output):

type Extra
index_merge Using intersect(f2,f4); Using where; Using index

The presence of the [NO_]INDEX_MERGE hint overrides the optimizer's
choice of keys during the index merge optimization. As we see in
the above example, keys f2 and f4 and given and the optimizer will
consider only those keys for this query.

When the hint is given without any particular keys, as in
INDEX_MERGE(table), then all keys are considered. In this case, the
cheapest index merge among the keys should be used. When
NO_INDEX_MERGE(table) is given, then index merge is disabled for
that table.

When the hint is given with one or more keys, then only those keys
are considered. In the case of NO_INDEX_MERGE, those keys are
excluded. This can lead to no merged indexes at all, because
there may not be sufficient row-ordered read columns available for
consideration.

The index merge strategies of intersection, union, and sort union
cannot themselves be directly controlled via the hints. In combination
with the optimizer switches for the same, the strategy may be
indirectly controlled but this is not guaranteed.

When the hint directs the optimizer such that insufficient ROR scans
are available, thus leading to a situation where the INDEX_MERGE hint
cannot be honored, the server will emit a warning to that effect.

In the hints module (opt_hints*{cc,h}), this commit adds some
index merge-specific functionality to make interpreting hint state
at callsites in the optimizer cleaner and more intuitive.
Particularly, we add a bit field to the table hints class which
indicates the keys that are marked by an [NO_]INDEX_MERGE hint, if
present. A new function, index_merge_hint (and associated new
helper functions) relies on this field when interpreting index merge
hint state for the optimizer.

If there are no index merges available prior to attemping to find
a suitable union/sort union, then the optimizer will not attempt
it. This change results in optimizer trace output which does not
include the 'analyzing_index_merge_union' block when there are no
merges.

Parts of this implementation based on MySQL commit
ebcb981807e3d91a64782e89d48e1a25622eafea 2025-05-02T18:38:46Z

Proxy download:

curl -#Lo /opt/percona80.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251019_2120_mysql/percona80-centos7-x86_64-20251019_1840.xz"

curl -#Lo /opt/mariadb.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251019_2120_mysql/mariadb-centos7-x86_64-20251019_1715.xz"

curl -#Lo /opt/percona80.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251019_2120_mysql/percona80-ubuntu-x86_64-20251019_0813.xz"

curl -#Lo /opt/fbmysql.zip "https://ghproxy.cfd/https://github.com/indiff/indiff/releases/download/20251019_2120_mysql/fbmysql-centos7-...