With this commit, we're enabling recursive planning for the
queries that used to fail due to recurring tuples.
We're simply returning the inner relations/subqueries to the caller
of the error check, which is then able to recursively plan them.
With this commit, we only pull&push the necessary columns. In this
context, necessary columns means that the columns that are required
for the query to be executed when the relation is wrapped into a
subquery.
We could potentially optimize things further:
(a) If a column only appears as a qual filter, we don't need to
pull it to the coordinator
(b) We currently pull unnecessary columns as NULL. However, we
could potentially adjust remaining of the query tree and do
not add columns of the relation to the target entry.
PostgreSQL already keeps track of the restrictions that are on the relation.
With this commit, Citus uses that information and pushes down the filters
to the subquery that is recursively planned for the table that is in
considiration.
Since flattening query may flatten outer joins' columns into coalesce expr that is
in the USING part, and that was not expected before this commit, these queries were
erroring out. It is fixed by this commit with considering coalesce expression as well.
We'd been ignoring updating uncrustify for some time now because I'd
thought these were misclassifications that would require an update in
our rules to address. Turns out they're legit, so I'm checking them in.
These hadn't been looked at in a while, and I'm somewhat certain they
actually were running with optimization on, which is pretty bad.
Swapped out the lower-level flags for `--coverage`, which will work
with both `clang` and `gcc`. On some platforms, linker flags are need-
ed as well.
The configuration for the build is in the YAML file; the changes to the
regression runner are backward-compatible with Travis and just add the
logic to detect whether our custom (isolation- and vanilla-enabled) pkg
is present.
Before this commit, round-robin task assignment policy was relying
on the taskId. Thus, even inside a transaction, the tasks were
assigned to different nodes. This was especially problematic
while reading from reference tables within transaction blocks.
Because, we had to expand the distributed transaction to many
nodes that are not necessarily already in the distributed transaction.
In this context, we define "Fast Path Planning for SELECT" as trivial
queries where Citus can skip relying on the standard_planner() and
handle all the planning.
For router planner, standard_planner() is mostly important to generate
the necessary restriction information. Later, the restriction information
generated by the standard_planner is used to decide whether all the shards
that a distributed query touches reside on a single worker node. However,
standard_planner() does a lot of extra things such as cost estimation and
execution path generations which are completely unnecessary in the context
of distributed planning.
There are certain types of queries where Citus could skip relying on
standard_planner() to generate the restriction information. For queries
in the following format, Citus does not need any information that the
standard_planner() generates:
SELECT ... FROM single_table WHERE distribution_key = X; or
DELETE FROM single_table WHERE distribution_key = X; or
UPDATE single_table SET value_1 = value_2 + 1 WHERE distribution_key = X;
Note that the queries might not be as simple as the above such that
GROUP BY, WINDOW FUNCIONS, ORDER BY or HAVING etc. are all acceptable. The
only rule is that the query is on a single distributed (or reference) table
and there is a "distribution_key = X;" in the WHERE clause. With that, we
could use to decide the shard that a distributed query touches reside on
a worker node.
Failure&Cancellation tests for initial start_metadata_sync() calls
to worker and DDL queries that send metadata syncing messages to an MX node
Also adds message type definitions for messages that are exchanged
during metadata syncing
-
We used to error out if there is a reference table
in the query participating a union. This has caused
pushdownable queries to be evaluated in coordinator.
Now we let reference tables inside union queries as long
as there is a distributed table in from clause.
Existing join checks (reference table on the outer part)
sufficient enought that we do not need check the join relation
of reference tables.
Previously we allowed task assignment policy to have affect on router queries
with only intermediate results. However, that is erroneous since the code-path
that assigns placements relies on shardIds and placements, which doesn't exists
for intermediate results.
With this commit, we do not apply task assignment policies when a router query
hits only intermediate results.
PG recently started propagating foreign key constraints
to partition tables. This came with a select query
to validate the the constaint.
We are already setting sequential mode execution for this
command. In order for validation select query to respect
this setting we need to explicitly set the GUC.
This commit also handles detach partition part.
Onder Kalaci
Murat Tuncer
Murat Tuncer
Hadi Moshayedi
Burak Velioglu
velioglu
Jason Petersen
Jason Petersen
Marco Slot
Nils Dijk
Hanefi Onaldi
Hanefi Onaldi
Nils Dijk