Skip to content

Can logical plan depends on connector? #591

@MBkkt

Description

@MBkkt

There's multiple reasons why do we in serenedb think it will be helpful.

In general I think dependency order like this

  1. common
  2. connector
  3. logical_plan
    4.1. runner
    4.2. optimizer

Why is it helpful?

In serenedb our pipeline like this:

  1. parse query text
  2. collect everything (in hashmap like struct) that looks like catalog reference from pg parser ast
  3. resolve (single time one for all => DDL snapshot) collected catalog objects via catalog
  4. use resolved objects in our PlanBuilder-like class to build logical_plan from pg parser ast

Right now we pass inside Axiom logical plan fake names that will be resolved with our own SchemaResolver that is knows that this is fake.
It's not convenient, neither effective.
It will be really convenient to create logical plan objects with already known table ptr/etc.

Btw in such case we can remove std::enable_shared_from from axiom::connector::Table maybe something else
For an example common Session will be unnecessary abstraction in such case.

How this would look for Axiom tests/Hive connector/etc?

I will add/move resolve + resolve cache in logical_plan PlanBuilder.

CC: @mbasmanova WDYT?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions