vaefremov95 commented on issue #1755:
URL: https://github.com/apache/arrow-adbc/issues/1755#issuecomment-5026011913
@lidavidm @Mandukhai-Alimaa
Hi!
I did a small research around **point 2** (the query optimization I
suggested earlier), can be useful here. I ran the optimized queries against a
range of Postgres-compatible databases to check exactly the compatibility
concern you raised.
The optimized queries are compatible with every engine I could test that
implements `pg_inherits` - including all real-Postgres extensions/forks **and**
CockroachDB's emulated catalog. The only regression is on databases that don't
implement `pg_inherits` at all - CrateDB.
### Methodology
For each database I ran two checks:
1. **Executability** - run the optimized queries literally against the full
catalog. This is the core compatibility question.
2. **Correctness** - create a representative schema and compare the
**original (unfiltered)** query vs the **optimized** one, restricted to that
schema:
- regular table, view, materialized view, composite type,
- a range-**partitioned** table with two child partitions (exercises the
`pg_inherits` filter).
The optimized query is correct if it drops **exactly** what it should -
partition children (via `pg_inherits`), system columns (`attnum <= 0`), and
non-table relkinds (indexes) - while keeping the real columns of real
relations; and for query B keeps base types (`typrelid = 0`) and rowtypes of
real relations while dropping rowtypes of partition children.
### Results
| Database | Version | Executable | Regression vs original? | Verdict |
|---|---|---|---|---|
| PostgreSQL | 16 | ✅ | no | ✅ OK (baseline) |
| Citus | PG 18.4 | ✅ | no | ✅ OK |
| TimescaleDB | PG 16.14 | ✅ | no | ✅ OK |
| ParadeDB | PG 18.4 | ✅ | no | ✅ OK |
| YugabyteDB | PG 15.12 | ✅ | no | ✅ OK |
| CockroachDB | 26.2 | ✅ | no | ✅ OK |
| CedarDB | v2026-07-10 (PG 16.3-compat) | ✅ | no | ✅ OK (see notes) |
| **CrateDB** | 6.3.5 | ❌ | **yes** | ❌ **FAIL** |
| Greenplum | GP6 | ✅ | no | ✅ OK (verified in production) |
I couldn't run **Neon**, **AlloyDB** or **Yellowbrick** locally (cloud-only
/ no public build). Neon and AlloyDB use a real Postgres catalog, so I'd expect
them to behave like stock PostgreSQL, but I haven't verified that.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
