Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-57

Select fields not pushed down to rules when using a View definition

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:

      Description

      Granted I don't understand this, but I'm filing a bug because I've sat here for days and can't figure out a way around it.

      If you use the MongoDB plugin it uses a View in the definition file. That view is then used during the query optimization process and the ProjectRel that are generated use the Select statement from the View when matching the rules.

      I would like to select only the fields used from Mongo rather than the whole table, this will minimise data transfer and enable Mongo Aggregation stuff, but currently all the fields are returned and I can't find a way to create a rule that is processed with just the fields selected.

      -Edit-

      Also, if I put break points into optiq-csv, the ProjectRels created there have the correct number of fields

      ---------------- Imported from GitHub ----------------
      Url: https://github.com/julianhyde/optiq/issues/57
      Created by: buggtb
      Labels:
      Created at: Tue Oct 01 12:02:47 CEST 2013
      State: closed

        Activity

        Hide
        github-import GitHub Import added a comment -

        [Date: Tue Oct 01 19:25:32 CEST 2013, Author: julianhyde]

        I presume this is specific to the MongoDB adapter. Can you reproduce this using an Explain Plan on the builtin Zips or Foodmart schemas?

        Show
        github-import GitHub Import added a comment - [Date: Tue Oct 01 19:25:32 CEST 2013, Author: julianhyde ] I presume this is specific to the MongoDB adapter. Can you reproduce this using an Explain Plan on the builtin Zips or Foodmart schemas?
        Hide
        github-import GitHub Import added a comment -

        [Date: Tue Oct 01 20:15:30 CEST 2013, Author: buggtb]

        I think its specific to any adapter that uses a View SQL snippet in
        Optiq, although this may only be Mongo currently.

        If you count the exprs in the MongoRules with zips you'll see its always 6.
        If you put a break point in on SqlToRelConverter.java at line 1780 where
        it says

        if (shouldConvertTableAccess)

        The user defined SQL gets as far as there but is then replaced forever
        more as far as I can tell with the SQL from the View.

        Cheers

        Tom

        On 01/10/13 18:25, Julian Hyde wrote:
        >
        > I presume this is specific to the MongoDB adapter. Can you reproduce
        > this using an Explain Plan on the builtin Zips or Foodmart schemas?
        >
        > —
        > Reply to this email directly or view it on GitHub
        > <https://github.com/julianhyde/optiq/issues/57#issuecomment-25470810>.
        >

        Show
        github-import GitHub Import added a comment - [Date: Tue Oct 01 20:15:30 CEST 2013, Author: buggtb ] I think its specific to any adapter that uses a View SQL snippet in Optiq, although this may only be Mongo currently. If you count the exprs in the MongoRules with zips you'll see its always 6. If you put a break point in on SqlToRelConverter.java at line 1780 where it says if (shouldConvertTableAccess) The user defined SQL gets as far as there but is then replaced forever more as far as I can tell with the SQL from the View. Cheers Tom On 01/10/13 18:25, Julian Hyde wrote: > > I presume this is specific to the MongoDB adapter. Can you reproduce > this using an Explain Plan on the builtin Zips or Foodmart schemas? > > — > Reply to this email directly or view it on GitHub > < https://github.com/julianhyde/optiq/issues/57#issuecomment-25470810 >. >
        Hide
        github-import GitHub Import added a comment -
        Show
        github-import GitHub Import added a comment - [Date: Tue Oct 15 06:47:35 CEST 2013, Author: julianhyde ] Fixed in https://github.com/julianhyde/optiq/commit/4218f9143cbe80343e842c6002c4d9ed2402fbcb .

          People

          • Assignee:
            Unassigned
            Reporter:
            github-import GitHub Import
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development