[MDEV-22535] TABLE::initialize_quick_structures() takes 0.5% in oltp_read_only Created: 2020-05-12  Updated: 2020-07-04  Resolved: 2020-07-03

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.1, 10.2, 10.3, 10.4, 10.5
Fix Version/s: 10.3.24, 10.4.14, 10.5.5

Type: Bug Priority: Major
Reporter: Sergey Vojtovich Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Problem/Incident
is caused by MDEV-20519 Query plan regression with optimizer_... Closed
Epic Link: Performance: micro optimizations

 Description    

void TABLE::initialize_quick_structures()
 
{
 
  bzero(quick_rows, sizeof(quick_rows));
 
  bzero(quick_key_parts, sizeof(quick_key_parts));
 
  bzero(quick_costs, sizeof(quick_costs));
 
  bzero(quick_n_ranges, sizeof(quick_n_ranges));
 
}

1. These members consume 1536 of 3520 bytes (44%) of TABLE for no good reason.
2. I doubt these arrays have to be fully initialized. I'd say they have to be initialized up to the number of indexes in the table.
3. Assuming these are per-key variables, they should be part of something like KEY rather than something like TABLE.
4. I generally recommend not using pre-initialization for performance reasons, but also because it tends to hide bugs from uninit-var detectors.

 Comments   
Comment by Varun Gupta (Inactive) [ 2020-05-13 ]

@Monty suggested to remove the initialisation and always check first if quick_keys is set only then use the quick
structures array. He requested to change the initialisation to undefined memory under valgrind

Comment by Varun Gupta (Inactive) [ 2020-06-18 ]

Patch
https://github.com/MariaDB/server/commit/e005f4db78c3fd08a33c87e2bcb8b6055e929ed9

The patch currently just moves the initialisation from TABLE::init to test_quick_select where we run the range optimizer.

Comment by Michael Widenius [ 2020-06-24 ]

I am working on a fix for this in 10.6; Let see how it looks when I am done if we should backport it to earlier versions.

Comment by Michael Widenius [ 2020-06-30 ]

Fix for 10.5 done and tested.
Have done a simpler and safer fix for 10.3. However to be able to push this, I need first to get 10.3 working with valgrind.
Working now on 10.3 and valgrind

Comment by Michael Widenius [ 2020-07-03 ]

Testing, merging, testing etc (Lot's of valgrind run's to verify that the change is safe)

10.3 & 10.4 fixed by not doing the initialization at all.
In 10.5 I do separate allocation for the table->quick items and instead of allocation MAX_KEY items,
we now only allocate as much space as we need. This made the TABLE structure much smaller,
(3528 -> 984 + keyinfo), which should save space and increase performance.

Generated at Thu Feb 08 09:15:28 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.