Feature #7675 - EXPLAIN statement and RDB$SQL package.

[asfernandes]

No description provided.

[sim1984]

Plan output in explain format is broken. Although RDB$SQL.EXPLAIN itself determines the level correctly, the indentation in the explain format is not correct.

Firebird 4.0

SQL> set planonly;
SQL> select count(*)
CON> from horse h
CON> join color on color.code_color = h.code_color
CON> where color.NAME_DE = '';

Select Expression
    -> Aggregate
        -> Nested Loop Join (inner)
            -> Filter
                -> Table "COLOR" Full Scan
            -> Filter
                -> Table "HORSE" as "H" Access By ID
                    -> Bitmap
                        -> Index "FK_HORSE_COLOR" Range Scan (full match)

Firebird 5.0 with explain feature

SQL> explain select count(*)
CON> from horse h
CON> join color on color.code_color = h.code_color
CON> where color.NAME_DE = '';

Select Expression
    -> Aggregate
        -> Nested Loop Join (inner)
            -> Filter
                -> Table "COLOR" Full Scan
            -> Filter
                -> Table "HORSE" as "H" Access By ID
    -> Bitmap
        -> Index "FK_HORSE_COLOR" Range Scan (full match)

The likely reason for this is the contents of the ACCESS_PATH column

-> Table "HORSE" as "H" Access By ID
     -> Bitmap
         -> Index "FK_HORSE_COLOR" Range Scan (full match)

The indentation for the first line is correct, but the indentation for subsequent lines is not added to the indentation.

[sim1984]

In addition, it would be nice to reserve columns for the future
CARDINALITY [BIG]INT,
COST DOUBLE PRECISION

[dyemanov]

Cardinality may already be returned.

[sim1984]

Here is another question, why?
-> Bitmap
And
-> Index "FK_HORSE_COLOR" Range Scan (full match)
are not separate entries?

I understand that here the plan is parsed in terms of sources of records. However, when parsing the plan itself, it would be convenient to see the indexes used as entity names, rather than parsing inside the ACCESS_PATH.

[sim1984]

It would also be nice to add an OBJECT_TYPE column: (table, procedure ...)

[asfernandes]

Here is another question, why? -> Bitmap And -> Index "FK_HORSE_COLOR" Range Scan (full match) are not separate entries?

I understand that here the plan is parsed in terms of sources of records. However, when parsing the plan itself, it would be convenient to see the indexes used as entity names, rather than parsing inside the ACCESS_PATH.

Every record returned matches a RecordSource, that is the bases also of the profiler. If we broke this rule, it will not be good to have different representations in these two places.

See topic "Detailed plan" that I started in fb-devel about the indentations without levels.

[asfernandes]

Should we also add a columns for the internal RecordSource class name?

[sim1984]

The line indentation for BitmapTableScan is fairly easy to fix. It is enough to add the current indent not to the entire ACCESS_PATH line, but to the line itself and after each line break.
Here is another problem. The use of some index is important information, in the current form it is necessary to parse ACCESS_PATH to get it.

[asfernandes]

It would also be nice to add an OBJECT_TYPE column: (table, procedure ...)

I added it, using same code as MON$COMPILED_STATEMENT.MON$OBJECT_TYPE.

I do not like it too much (in most cases a string string is better for such things IMO), but did to be consistent.

Profiler uses a string for STATEMENT_TYPE, but there it could also be BLOCK.

[sim1984]

In some cases, the output parameter ACCESS_PATH VARCHAR(255) may not be long enough. This will happen when bitmasks are combined. Example:

SELECT *
FROM RDB$SQL.EXPLAIN(Q'{
SELECT *
FROM RDB$RELATIONS
WHERE RDB$RELATIONS.RDB$RELATION_NAME IN ('RDB$PAGES', 'RDB$DATABASE', 'RDB$FIELDS')
}');

Arithmetic overflow or division by zero has occurred.
arithmetic exception, numeric overflow, or string truncation.
string right truncation.
expected length 255, actual 342.
-------------------------------------------------------------
SQLCODE: -802
SQLSTATE: 22001
GDSCODE: 335544321

[sim1984]

In addition, the padding for Bitmap And is displayed incorrectly and the Legacy plan breaks (extra comma).

select *
from RDB$INDICES
where RDB$FOREIGN_KEY = 'RDB$RELATION_ID'
  and RDB$RELATION_NAME = 'RDB$RELATIONS'

Legacy plan:

PLAN (RDB$INDICES INDEX (, RDB$INDEX_31, RDB$INDEX_41))

Explain plan:

Select Expression
    -> Filter
        -> Table "RDB$INDICES" Access By ID
            -> Bitmap And
                -> Bitmap
                    -> Index "RDB$INDEX_31" Range Scan (full match)
                        -> Bitmap
                            -> Index "RDB$INDEX_41" Range Scan (full match)

[asfernandes]

In some cases, the output parameter ACCESS_PATH VARCHAR(255) may not be long enough. This will happen when bitmasks are combined.

Any opinions if we enlarge it or just use text blob?

[asfernandes]

In addition, the padding for Bitmap And is displayed incorrectly and the Legacy plan breaks (extra comma).

Let's wait merge of #7709 to fix, it will create conflicts with this.

[AlexPeshkoff]

On 8/15/23 12:30, Adriano dos Santos Fernandes wrote: In some cases, the output parameter ACCESS_PATH VARCHAR(255) may not be long enough. This will happen when bitmasks are combined. Any opinions if we enlarge it or just use text blob?

I see no problems with use of text blob here.