Marios Trivyzas

> If time were difficult to check maybe this could take the form of some other limit? (number of iterations or something like that) We have iteration counting in query...

1. A naive approach that we can backport would be to just add a count of how much time is spent on each step (parser, analyzer, planner) and check for...

Using just a separate thread and using the scheduler, won't solve the issue of being able to interrupt the execution at any point, as there needs to be a repeated...

After playing around a bit, the solution I can think so far, is to use the root column name of the json col in postgres, to be able to get...

Closing in favor of a different approach: https://github.com/crate/crate/pull/16251

This is what you mean, right? ``` cr> create table t1(x int, y int); CREATE OK, 1 row affected (0.356 sec) cr> explain SELECT * FROM (select * from t1...

Is there any progress on this @katerinarousi ? Do you need any more help to proceed?

Thank you for the initial try to work on this, but since this PR has been stale for long time, I'm closing this. As long as the issue is still...

Issue has been partially addressed by: https://github.com/crate/crate/pull/16098, but possibly there can be room for improvement: smarter pk extraction (at least for certain cases) - avoid cartesian product.

Findings: - Postgres doesn't apply user settings when switching users with `SET SESSION AUTHORIZATION`: (`search_path` is set to `myschema` for user `u1`) ``` $ psql -U u postgres psql (16.2)...