**Describe what's wrong**

Wrong table name in logs after table `RENAME`


**Does it reproduce on recent release?**

Yes.
**How to reproduce**
22.6

```
CREATE TABLE table_test_a
(
    `key` UInt32
)
ENGINE = MergeTree
ORDER BY key;

INSERT INTO table_test_a SELECT *
FROM numbers(1000);

RENAME TABLE table_test_a TO table_test_b;

SELECT *
FROM table_test_b
FORMAT `Null`;


[LAPTOP-] 2022.06.13 10:58:18.370192 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Debug> executeQuery: (from 127.0.0.1:58484) SELECT * FROM table_test_b FORMAT Null; (stage: Complete)
[LAPTOP-] 2022.06.13 10:58:18.370599 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Trace> ContextAccess (default): Access granted: SELECT(key) ON test.table_test_b
[LAPTOP-] 2022.06.13 10:58:18.370665 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Trace> ContextAccess (default): Access granted: SELECT(key) ON test.table_test_b
[LAPTOP-] 2022.06.13 10:58:18.370714 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Trace> InterpreterSelectQuery: FetchColumns -> Complete
[LAPTOP-] 2022.06.13 10:58:18.370783 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Debug> test.table_test_a (SelectExecutor): Key condition: unknown
[LAPTOP-] 2022.06.13 10:58:18.370817 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Debug> test.table_test_a (SelectExecutor): Selected 1/1 parts by partition key, 1 parts by primary key, 1/1 marks by primary key, 1 marks to read from 1 ranges
[LAPTOP-] 2022.06.13 10:58:18.370847 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Trace> MergeTreeInOrderSelectProcessor: Reading 1 ranges in order from part all_1_1_0, approx. 1000 rows starting from 0
[LAPTOP-] 2022.06.13 10:58:18.371812 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Information> executeQuery: Read 1000 rows, 3.91 KiB in 0.0015354 sec., 651296 rows/sec., 2.48 MiB/sec.
[LAPTOP-] 2022.06.13 10:58:18.371956 [ 27745 ] {43b0dc5d-69e6-4e42-b96c-a13871b6a791} <Debug> MemoryTracker: Peak memory usage (for query): 45.10 KiB.
```
**Expected behavior**

Correct table name in logs


**Additional context**

Interesting, does it affect grants and etc (looks like no, in ContextAccess log it's using correct table name )

/
    /
    const auto time_now = std::chrono::system_clock::now();
    part_log_elem.event_time = time_in_seconds(time_now);
    part_log_elem.event_time_microseconds = time_in_microseconds(time_now);
    /
    part_log_elem.duration_ms = elapsed_ns / 1000000;
    part_log_elem.database_name = table_id.database_name;
    part_log_elem.table_name = table_id.table_name;
    part_log_elem.partition_id = MergeTreePartInfo::fromPartName(new_part_name, format_version).partition_id;
    part_log_elem.part_name = new_part_name;
    if (result_part)
    {
        part_log_elem.disk_name = result_part->data_part_storage->getDiskName();
        part_log_elem.path_on_disk = result_part->data_part_storage->getFullPath();
        part_log_elem.bytes_compressed_on_disk = result_part->getBytesOnDisk();
        part_log_elem.rows = result_part->rows_count;
        part_log_elem.part_type = result_part->getType();
    }
    part_log_elem.source_part_names.reserve(source_parts.size());
    for (const auto & source_part : source_parts)
        part_log_elem.source_part_names.push_back(source_part->name);
    if (merge_entry)
    {
        part_log_elem.rows_read = (*merge_entry)->rows_read;
        part_log_elem.bytes_read_uncompressed = (*merge_entry)->bytes_read_uncompressed;
        part_log_elem.rows = (*merge_entry)->rows_written;
        part_log_elem.bytes_uncompressed = (*merge_entry)->bytes_written_uncompressed;
        part_log_elem.peak_memory_usage = (*merge_entry)->memory_tracker.getPeak();
    }