Currently, get_useful_pathkeys_for_relation() only examines the list of expressions in each EquivalenceClass EquivalenceClass for each desired pathkey to see if there is an expression supported by ClickHouse. If there are none, or if any cannot be pushed down, it doesn't create a PathKey.
If, however, the relation has only a single ClickHouse table it ought to be possible to report the underlying sort order of the ClickHouse table, so the planner can take it into consideration when planning a query. Doing so would likely require annotating foreign tables with the underlying sort order.
IOW, while a sequential scan in Postgres should have zero PathKeys, a sequential scan of a ClickHouse table should have one for each column by which the table id ordered (or clustered) — or, rather 2 for each column, one ASC and one DESC.
Currently,
get_useful_pathkeys_for_relation()only examines the list of expressions in eachEquivalenceClassEquivalenceClassfor each desired pathkey to see if there is an expression supported by ClickHouse. If there are none, or if any cannot be pushed down, it doesn't create aPathKey.If, however, the relation has only a single ClickHouse table it ought to be possible to report the underlying sort order of the ClickHouse table, so the planner can take it into consideration when planning a query. Doing so would likely require annotating foreign tables with the underlying sort order.
IOW, while a sequential scan in Postgres should have zero
PathKeys, a sequential scan of a ClickHouse table should have one for each column by which the table id ordered (or clustered) — or, rather 2 for each column, one ASC and one DESC.