IMO, there is no easy way, and the algorithm should depends on definition
of 'alternative plans'.
In general, the algorithm can proceed like this:
1. we use the volcano algoirthm to find the best plan
2. we make the self cost of some node to be infinite, and then apply the
volcano algorithm again
The fact that PostgreSQL implements MERGE and “INSERT … ON CONFLICT” (so-called
UPSERT) differently with regard to consistency is an implementation detail in
PostgreSQL, and I refuse to accept it as rationale for what we do in Calcite.
(If we try to emulate the behavior of systems that suck… wel
There’s no easy way. You could modify ‘buildCheapestPlan()’ to build all plans
below a cost limit. (You’d have to carefully choose a cost limit only a little
above the optimal cost, otherwise you’ll get huge numbers of plans.)
I fear that you’ll get plans that are different in only trivial or mi
Hi there!
Just recently started to learn about Apache Calcite. What's the best way to
get a list of the k-cheapest alternative plans generated by the optimizer
for a given query? (being k an arbitrary number)
Il Mer 18 Mar 2020, 08:35 Christian Beikov ha
scritto:
> I'd argue that these technical details are in fact the reason why this
> is a different functionality, that deserves special handling.
>
> I expect an upsert statement like `INSERT INTO tbl(a, b) VALUES(1, 2) ON
> CONFLICT DO NOTHING` to ne
If a Janino exception comes up then it is a bug that we have to fix since
it violates the contract of the interface.
>From my point of view the modification is meaningful for two reasons:
* improves code readability;
* avoids confusing behavior where the rules for performing
constant reduction are
I'd argue that these technical details are in fact the reason why this
is a different functionality, that deserves special handling.
I expect an upsert statement like `INSERT INTO tbl(a, b) VALUES(1, 2) ON
CONFLICT DO NOTHING` to never produce a constraint violation.
This is functionally diff
