Skip to content

bug: incorrect motion policy for operators `!=`, `not in`

When resolving join/selection conflicts we try to use the same strategy for not in, != as we use for =, in

Error query:

config.yaml:

    i:
      format:
      - type: integer
        name: id1
        is_nullable: false
      - type: integer
        name: a1
        is_nullable: false
      - type: unsigned
        name: bucket_id
        is_nullable: false
      temporary: false
      indexes:
      - unique: true
        parts:
        - path: id1
          is_nullable: false
          type: integer
        type: TREE
        name: id1
      - unique: false
        parts:
        - path: bucket_id
          is_nullable: false
          type: unsigned
        type: TREE
        name: bucket_id
      is_local: false
      engine: memtx
      sharding_key:
      - id1

To reproduce 2 storadges are required: the table must be sharded.

test_app.router-1> sbroad.execute([[insert into "i" values (1, 1), (2, 2), (3, 3), (4, 4)]], {})
---
- {'row_count': 4}
...

test_app.router-1> sbroad.execute([[select * from "i" join (select "id1" as u from "i") as q  on "i"."id1" not in q.u]], {})
---
- {'metadata': [{'name': 'i.id1', 'type': 'integer'}, {'name': 'i.a1', 'type': 'integer'},
    {'name': 'Q.U', 'type': 'integer'}], 'rows': [[2, 2, 3], [2, 2, 4], [3, 3, 2],
    [3, 3, 4], [4, 4, 2], [4, 4, 3]]}
...

But in the last response there are no tuples: [1, 1, 2], [1, 1, 3], [1, 1, 4]