Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.6.16
-
None
Description
First off: I am not a DB expert.
Queries below are performed in a large table with around 130.000.000 entries.
I am using Mariadb 10.6.16
There are multiple issues reported on ROWID filter performance degradation, I am not sure if this matches an existing/open issue or not.
From time to time a SELECT query takes minutes where I would expect it to take milliseconds, I noticed that in every occurrence, the amount of entries returned (or matching the query) was very small.
The problematic query is as follows: (Hibernate generated, reduced to make it readable)
SELECT * |
FROM |
`payment_transaction` pt1_0 where pt1_0.`merchant_id`='<some id>' AND |
pt1_0.`device_id`='<some id>' |
order by pt1_0.`timestamp` desc |
There are both indices starting with MERCHANT_ID and DEVICE_ID, using either of these indices would limit the result to a mere 55 entries in 1 case. However, the query takes 3-4 minutes to complete.
I ran the following :
SET SESSION optimizer_switch='rowid_filter=on';
|
 |
DESCRIBE FORMAT=JSON
|
SELECT SQL_NO_CACHE *
|
FROM
|
`payment_transaction` pt1_0 where pt1_0.`merchant_id`='<some id>' and 1=1 AND
|
pt1_0.`device_id`='<some other id>'
|
order by pt1_0.`timestamp` desc
|
This yields:
{
|
"query_block": {
|
"select_id": 1,
|
"table": {
|
"table_name": "pt1_0",
|
"access_type": "ref",
|
"possible_keys": [
|
"idx_merchant_transactions",
|
"idx_device_id_shoplocation_id_payment_method_timestamp",
|
"idx_merchant_location",
|
"idx_device_seq_number"
|
],
|
"key": "idx_merchant_transactions",
|
"key_length": "109",
|
"used_key_parts": ["merchant_id"],
|
"ref": ["const"],
|
"rowid_filter": {
|
"range": {
|
"key": "idx_device_seq_number",
|
"used_key_parts": ["device_id"]
|
},
|
"rows": 55,
|
"selectivity_pct": 4.785047e-5
|
},
|
"rows": 55,
|
"filtered": 4.785047e-5,
|
"attached_condition": "pt1_0.merchant_id <=> '<some id>' and pt1_0.merchant_id = '<some id>' and pt1_0.device_id = '<some other id>'"
|
}
|
}
|
}
|
The total amount of rows is thus 55 (out of 132.000.000), which are returned instantly when using any of the four possible indices, but takes minutes with ROWID filtering.
The same query without ROWID filter:
{
|
"query_block": {
|
"select_id": 1,
|
"table": {
|
"table_name": "pt1_0",
|
"access_type": "ref",
|
"possible_keys": [
|
"idx_merchant_transactions",
|
"idx_device_id_shoplocation_id_payment_method_timestamp",
|
"idx_merchant_location",
|
"idx_device_seq_number"
|
],
|
"key": "idx_merchant_transactions",
|
"key_length": "109",
|
"used_key_parts": ["merchant_id"],
|
"ref": ["const"],
|
"rows": 55,
|
"filtered": 4.783742e-5,
|
"attached_condition": "pt1_0.merchant_id <=> '<some id>' and pt1_0.merchant_id = '<some id>' and pt1_0.device_id = '<some other id>'"
|
}
|
}
|
}
|
Attachments
Issue Links
- relates to
-
MDEV-26955 Improve the cost model for usage of in-memory range rowid / primary key filters
-
- Stalled
-
-
-
- Open
-