nix: add postgrest-with-oriole-17

[wolfgangwalther]

Tests PostgREST against orioledb, which is packaged on a temporary branch on my Nixpkgs fork. Thus, not ready for merging, yet.

We will be able to see some failing spec tests, though - did not check the other test suites, yet.

Open issues:

• nix: add postgrest-with-oriole-17 #4845 (comment): a plain SELECT with ANY clause uses a more costly custom/index scan in orioledb. It's questionable whether that's a bug or whether we'd just need to special case the cost estimation here.
• nix: add postgrest-with-oriole-17 #4845 (comment): MacOS build for orioledb fails, reported in Building on aarch64 MacOS / with LLVM 21 orioledb/postgres#65.

[akorotkov]

Thank you. Could we verify there are no known issues on OrioleDB's side?

[wolfgangwalther]

We'll have to clean this up first, before we can make another run comparing stock PG and orioledb. Will report back.

After doing that, only a few tests fail where we hardcoded a certain expectation of cost. The cost changed because a different plan was chosen - instead of "Seq Scan" it uses "Custom Scan":

The query should essentially be a simple SELECT ... FROM projects WHERE id IN (...) (inside the usual json aggregation wrapper).

PG 17:

curl -H "Accept: application/vnd.pgrst.plan+json" 'http://localhost:3000/projects?id=in.(1,2,3)'
[
  {
    "Plan": {
      "Node Type": "Aggregate",
      "Strategy": "Plain",
      "Partial Mode": "Simple",
      "Parallel Aware": false,
      "Async Capable": false,
      "Startup Cost": 1.09,
      "Total Cost": 1.11,
      "Plan Rows": 1,
      "Plan Width": 144,
      "Plans": [
        {
          "Node Type": "Seq Scan",
          "Parent Relationship": "Outer",
          "Parallel Aware": false,
          "Async Capable": false,
          "Relation Name": "projects",
          "Alias": "projects",
          "Startup Cost": 0.00,
          "Total Cost": 1.07,
          "Plan Rows": 3,
          "Plan Width": 15,
          "Filter": "(id = ANY ('{1,2,3}'::integer[]))"
        }
      ]
    }
  }
]

Oriole:

curl -H "Accept: application/vnd.pgrst.plan+json" 'http://localhost:3000/projects?id=in.(1,2,3)'
[
  {
    "Plan": {
      "Node Type": "Aggregate",
      "Strategy": "Plain",
      "Partial Mode": "Simple",
      "Parallel Aware": false,
      "Async Capable": false,
      "Startup Cost": 8.20,
      "Total Cost": 8.22,
      "Plan Rows": 1,
      "Plan Width": 144,
      "Plans": [
        {
          "Node Type": "Custom Scan",
          "Parent Relationship": "Outer",
          "Custom Plan Provider": "o_scan",
          "Parallel Aware": false,
          "Async Capable": false,
          "Relation Name": "projects",
          "Alias": "projects",
          "Startup Cost": 0.13,
          "Total Cost": 8.19,
          "Plan Rows": 3,
          "Plan Width": 15,
          "Scan Direction": "Forward",
          "Index Name": "projects_pkey",
          "Custom Scan Subtype": "Index Scan",
          "Index Cond": "(id = ANY ('{1,2,3}'::integer[]))"
        }
      ]
    }
  }
]

[wolfgangwalther]

There's one more thing that fails, which is the build on MacOS. I tracked the error message down to the thread that resulted in postgres/postgres@0dceba2, which does not seem to be present in orioledb/postgres. Reported as orioledb/postgres#65.

[wolfgangwalther]

After doing that, only a few tests fail where we hardcoded a certain expectation of cost. The cost changed because a different plan was chosen - instead of "Seq Scan" it uses "Custom Scan":

The query should essentially be a simple SELECT ... FROM projects WHERE id IN (...) (inside the usual json aggregation wrapper).

Looking at this some more makes me wonder whether the regular Seq Scan has just associated increased cost estimations now - and that's why the index scan is chosen in this case? Any idea, @akorotkov?

[akorotkov]

@wolfgangwalther, OrioleDB implements index-organized tables. Even if there is no primary key, OrioleDB organizes the table as an index over an invisible CTID column. It has an equivalent to seq scan, but it's internally different and has a different estimate.

[wolfgangwalther]

It has an equivalent to seq scan, but it's internally different and has a different estimate.

Thanks - that's what I suspected. So the different cost estimates / plans in this case are OK. I already tried building on MacOS - works now.

This means we have all test failures figured out, no questions remain.

(can't merge this before we sort out packaging issues in Nixpkgs, though)