nix: add postgrest-with-oriole-18

[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-18 #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-18 #4845 (comment): MacOS build for orioledb fails, reported in Building on aarch64 MacOS / with LLVM 21 orioledb/postgres#65.

TODO:

• Add howto to docs
• Special-case cost estimations for orioledb in tests

[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)

[steve-chavez]

Maybe we should add a small guide on https://docs.postgrest.org/en/v14/integrations/ after this is merged, showing how to use the NixOS postgres module with Orioledb, also mentioning that we test against it. (at some point I remember we had a Greenplum integration, but wasn't really tested).

[wolfgangwalther]

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

This is resolved now, orioledb is a package available in Nixpkgs by now and this PR updates to latest nixpkgs-unstable which has it.

Still need to find a way to special-case the tests for the different cost estimates and write that small integration/howto.

Edit: Currently waiting on NixOS/nixpkgs#540609, though, because postgis is failing to build right now.

[wolfgangwalther]

There now seems to be another failing test that we either missed earlier or that came along in the meantime - I think I updated orioledb to a newer version before merging it in Nixpkgs, so that could be the case. (test results are not online, I only have them locally with a fixed gdal/postgis)

It's the Feature.Query.PlanSpec.spec, read table/view plan, includes the Query Identifier field when using the verbose option test that is failing.

Comparing PG 17 and orioledb 17:

orioledb=# EXPLAIN VERBOSE SELECT 1 FROM pg_catalog.pg_class;
                                                     QUERY PLAN
---------------------------------------------------------------------------------------------------------------------
 Index Only Scan using pg_class_tblspc_relfilenode_index on pg_catalog.pg_class  (cost=0.15..14.37 rows=415 width=4)
   Output: 1
(2 rows)

postgres=# EXPLAIN VERBOSE SELECT 1 FROM pg_catalog.pg_class;
                                                     QUERY PLAN
---------------------------------------------------------------------------------------------------------------------
 Index Only Scan using pg_class_tblspc_relfilenode_index on pg_catalog.pg_class  (cost=0.15..14.37 rows=415 width=4)
   Output: 1
 Query Identifier: 6021251728203401518
(3 rows)

Orioledb does not show the query identifier on EXPLAIN VERBOSE anymore.

[steve-chavez]

It's the Feature.Query.PlanSpec.spec, read table/view plan, includes the Query Identifier field when using the verbose option test that is failing.

@wolfgangwalther Can't reproduce this branch locally, I get a postgis compile error (after considerable time compiling). How do you manage to run the tests to get the above error?

[wolfgangwalther]

Can't reproduce this branch locally, I get a postgis compile error (after considerable time compiling). How do you manage to run the tests to get the above error?

I updated my nixpkgs branch locally to one that contains the fix for that compilation problem. It's from some random PR, so I did not push it.

This PR has merged and I'm watching the channels at https://nixpk.gs/pr-tracker.html?pr=540826 - once this hits nixpkgs-unstable, I will update this branch and push it. You can then see it in CI.

Edit: Note that this will also include NixOS/nixpkgs#541173, i.e. will update orioledb's postgres from 17 to 18. So we might see different results anyway.

[wolfgangwalther]

(did not test, just pushed the new nixpkgs pin - let's see what CI says, we might need to fix more things, always a chance on a bump)

[wolfgangwalther]

Note that this will also include NixOS/nixpkgs#541173, i.e. will update orioledb's postgres from 17 to 18. So we might see different results anyway.

In my local tests this did not make a difference.

I pushed builds to cachix, so hopefully the CI job will not timeout this time. Let's see...

[wolfgangwalther]

I have no idea why the style-check fails in CI, it does not for me locally.

[steve-chavez]

I have no idea why the style-check fails in CI, it does not for me locally.

That has happened before for me too. I think the CI picks a different (newer) version of the python linter.

[wolfgangwalther]

I think the CI picks a different (newer) version of the python linter.

That should certainly not happen because Nix pins all those dependencies for us.

It was a different problem: postgrest-style was just piping stderr for those linters to /dev/null, so an error that only occured on my system went silent. The command was actually failing for me, but didn't produce a diff.

Fixed that and then it went on to reformat the same files as CI.

Now the only remaining failure will be the spec test failure about the missing Query Identifier. We should probably report that upstream.

[steve-chavez]

Reported upstream orioledb/postgres#72