Slow query execution in Firebird

My executed SQL query is as follows:

update elements E
    set E.END_I = (select n.node_num
                   from nodes N 
                   where abs(E.X_I - N.XI) < 0.001 and
                         abs(E.Y_I - N.YI) < 0.001 and
                         abs(E.Z_I - N.ZI) < 0.001
                  )

It takes about 24 seconds to complete, I read about troubleshooting firebird. Why is my database query slow? He instructs to create indexes for related fields in the table, and I added reduction / increase indexes for the XI, YI, ZI fields in both Nodes and Elements tables. But still, the performance is very slow, there are 6,677 rows in the database, and I use FlameRobin as an SQL editor.

The interesting thing: as shown in the Firebird troubleshooting guide, which has

If you see a NATURAL plan against a large table, you have found a Problem

this error is described as a bad case and a source of slowdown, the recommended solution is to create decreasing indices for related fields. But in my case, even after defining the indexes, it seems that I still suffer from this PLAN (N NATURAL), PLAN (E NATURAL), which is reported at the output of Flamerobin, as shown below.

How can I rule this out?

Preparing query: update elements E set E.END_I = (select n.node_num from nodes N 
where abs(E.X_I-N.XI)<0.001 and abs(E.Y_I - N.YI)<0.001 and abs(E.Z_I-N.ZI)<0.001 )
Prepare time: 0.004s
PLAN (N NATURAL)
PLAN (E NATURAL)

Executing...
Done.
108818273 fetches, 79227 marks, 4050 reads, 9380 writes.
0 inserts, 6677 updates, 0 deletes, 0 index, 14549183 seq.
Delta memory: 212 bytes.
ELEMENTS: 6677 updates. 
6677 rows affected directly.
Total execution time: 24.038s
Script execution finished.

CREATE DESCENDING INDEX IDX_ELEMENTS1 ON ELEMENTS (Z_I);
CREATE DESCENDING INDEX IDX_XI ON ELEMENTS (X_I);
CREATE DESCENDING INDEX IDX_YI ON ELEMENTS (Y_I);
GRANT DELETE, INSERT, REFERENCES, SELECT, UPDATE
 ON ELEMENTS TO  SYSDBA WITH GRANT OPTION;

CREATE DESCENDING INDEX IDX_NODES1_XI ON NODES (XI);
CREATE DESCENDING INDEX IDX_NODES1_YI ON NODES (YI);
CREATE DESCENDING INDEX IDX_NODES1_ZI ON NODES (ZI);
GRANT DELETE, INSERT, REFERENCES, SELECT, UPDATE
 ON NODES TO  SYSDBA WITH GRANT OPTION;
+4
source share
3 answers

Your query is slowed down with a function abs()because the index on the bare column does not work with expressions. Try changing the query to at least give db the ability to use the index

update elements E
    set E.END_I = (select n.node_num
                   from nodes N 
                   where N.XI < E.X_I + 0.001 AND N.XI > E.X_I - 0.001
                   AND N.YI < E.Y_I + 0.001 AND N.YI > E.Y_I - 0.001
                   AND N.ZI < E.Z_I + 0.001 AND N.ZI > E.Z_I - 0.001
                  )
+2
source

Create indexes in columns X_I, Y_I, Z_I, then run the statement:

MERGE INTO elements dst
   USING (
    SELECT e.x_i, e.y_i, e.z_i, n.node_num
    FROM nodes N JOIN elements E ON 
      abs(E.X_I - N.XI) < 0.001 and
      abs(E.Y_I - N.YI) < 0.001 and
      abs(E.Z_I - N.ZI) < 0.001
   ) src
ON dst.X_I = src.X_I AND dst.Y_I = src.Y_I AND dst.Z_I = src.Z_I
WHEN MATCHED THEN UPDATE SET dst.END_I = src.NODE_NUM

fooobar.com/questions/1623268/..., ABS XI, YI, ZI N .

0

Perhaps something like this might help:

1) Create a Cartesian product between the tables, calculating X, Y and Z.

2) Filter only the desired entries.

3) Update element entries using the value of node_num.

execute block
as
declare variable key integer; -- primary key type
declare variable node_num integer; -- node_num type
begin
  for
    select
      key,
      node_num
    from (
      select
        E.key, -- primary key name
        N.node_num,
        abs(E.X_I - N.XI) as X,
        abs(E.Y_I - N.YI) as Y,
        abs(E.Z_I - N.ZI) as Z
      from elements E, nodes N)
    where (X < 0.001)
      and (Y < 0.001)
      and (Z < 0.001)
    into
      :key,
      :node_num
  do
  begin
    update elements set
      END_ID = :node_num
    where elements.key = :key; -- primary key name
  end
end
0
source

Source: https://habr.com/ru/post/1623268/


All Articles