2013-02-21 11:26:23 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- create FDW objects
|
|
|
|
-- ===================================================================
|
|
|
|
|
|
|
|
CREATE EXTENSION postgres_fdw;
|
|
|
|
|
|
|
|
CREATE SERVER testserver1 FOREIGN DATA WRAPPER postgres_fdw;
|
2014-08-26 02:54:53 +02:00
|
|
|
DO $d$
|
|
|
|
BEGIN
|
|
|
|
EXECUTE $$CREATE SERVER loopback FOREIGN DATA WRAPPER postgres_fdw
|
2014-08-26 12:21:06 +02:00
|
|
|
OPTIONS (dbname '$$||current_database()||$$',
|
|
|
|
port '$$||current_setting('port')||$$'
|
|
|
|
)$$;
|
2016-02-09 20:00:50 +01:00
|
|
|
EXECUTE $$CREATE SERVER loopback2 FOREIGN DATA WRAPPER postgres_fdw
|
|
|
|
OPTIONS (dbname '$$||current_database()||$$',
|
|
|
|
port '$$||current_setting('port')||$$'
|
|
|
|
)$$;
|
2021-01-18 07:11:08 +01:00
|
|
|
EXECUTE $$CREATE SERVER loopback3 FOREIGN DATA WRAPPER postgres_fdw
|
|
|
|
OPTIONS (dbname '$$||current_database()||$$',
|
|
|
|
port '$$||current_setting('port')||$$'
|
|
|
|
)$$;
|
2014-08-26 02:54:53 +02:00
|
|
|
END;
|
|
|
|
$d$;
|
2013-02-21 11:26:23 +01:00
|
|
|
|
|
|
|
CREATE USER MAPPING FOR public SERVER testserver1
|
|
|
|
OPTIONS (user 'value', password 'value');
|
|
|
|
CREATE USER MAPPING FOR CURRENT_USER SERVER loopback;
|
2016-02-09 20:00:50 +01:00
|
|
|
CREATE USER MAPPING FOR CURRENT_USER SERVER loopback2;
|
2021-01-18 07:11:08 +01:00
|
|
|
CREATE USER MAPPING FOR public SERVER loopback3;
|
2013-02-21 11:26:23 +01:00
|
|
|
|
|
|
|
-- ===================================================================
|
|
|
|
-- create objects used through FDW loopback server
|
|
|
|
-- ===================================================================
|
|
|
|
CREATE TYPE user_enum AS ENUM ('foo', 'bar', 'buz');
|
|
|
|
CREATE SCHEMA "S 1";
|
|
|
|
CREATE TABLE "S 1"."T 1" (
|
|
|
|
"C 1" int NOT NULL,
|
|
|
|
c2 int NOT NULL,
|
|
|
|
c3 text,
|
|
|
|
c4 timestamptz,
|
|
|
|
c5 timestamp,
|
|
|
|
c6 varchar(10),
|
|
|
|
c7 char(10),
|
|
|
|
c8 user_enum,
|
|
|
|
CONSTRAINT t1_pkey PRIMARY KEY ("C 1")
|
|
|
|
);
|
|
|
|
CREATE TABLE "S 1"."T 2" (
|
|
|
|
c1 int NOT NULL,
|
|
|
|
c2 text,
|
|
|
|
CONSTRAINT t2_pkey PRIMARY KEY (c1)
|
|
|
|
);
|
2016-02-09 20:00:50 +01:00
|
|
|
CREATE TABLE "S 1"."T 3" (
|
|
|
|
c1 int NOT NULL,
|
|
|
|
c2 int NOT NULL,
|
|
|
|
c3 text,
|
|
|
|
CONSTRAINT t3_pkey PRIMARY KEY (c1)
|
|
|
|
);
|
|
|
|
CREATE TABLE "S 1"."T 4" (
|
|
|
|
c1 int NOT NULL,
|
|
|
|
c2 int NOT NULL,
|
|
|
|
c3 text,
|
|
|
|
CONSTRAINT t4_pkey PRIMARY KEY (c1)
|
|
|
|
);
|
2013-02-21 11:26:23 +01:00
|
|
|
|
2018-03-02 19:16:01 +01:00
|
|
|
-- Disable autovacuum for these tables to avoid unexpected effects of that
|
|
|
|
ALTER TABLE "S 1"."T 1" SET (autovacuum_enabled = 'false');
|
|
|
|
ALTER TABLE "S 1"."T 2" SET (autovacuum_enabled = 'false');
|
|
|
|
ALTER TABLE "S 1"."T 3" SET (autovacuum_enabled = 'false');
|
|
|
|
ALTER TABLE "S 1"."T 4" SET (autovacuum_enabled = 'false');
|
|
|
|
|
2013-02-21 11:26:23 +01:00
|
|
|
INSERT INTO "S 1"."T 1"
|
|
|
|
SELECT id,
|
|
|
|
id % 10,
|
|
|
|
to_char(id, 'FM00000'),
|
|
|
|
'1970-01-01'::timestamptz + ((id % 100) || ' days')::interval,
|
|
|
|
'1970-01-01'::timestamp + ((id % 100) || ' days')::interval,
|
|
|
|
id % 10,
|
|
|
|
id % 10,
|
|
|
|
'foo'::user_enum
|
|
|
|
FROM generate_series(1, 1000) id;
|
|
|
|
INSERT INTO "S 1"."T 2"
|
|
|
|
SELECT id,
|
|
|
|
'AAA' || to_char(id, 'FM000')
|
|
|
|
FROM generate_series(1, 100) id;
|
2016-02-09 20:00:50 +01:00
|
|
|
INSERT INTO "S 1"."T 3"
|
|
|
|
SELECT id,
|
|
|
|
id + 1,
|
|
|
|
'AAA' || to_char(id, 'FM000')
|
|
|
|
FROM generate_series(1, 100) id;
|
|
|
|
DELETE FROM "S 1"."T 3" WHERE c1 % 2 != 0; -- delete for outer join tests
|
|
|
|
INSERT INTO "S 1"."T 4"
|
|
|
|
SELECT id,
|
|
|
|
id + 1,
|
|
|
|
'AAA' || to_char(id, 'FM000')
|
|
|
|
FROM generate_series(1, 100) id;
|
|
|
|
DELETE FROM "S 1"."T 4" WHERE c1 % 3 != 0; -- delete for outer join tests
|
2013-02-21 11:26:23 +01:00
|
|
|
|
|
|
|
ANALYZE "S 1"."T 1";
|
|
|
|
ANALYZE "S 1"."T 2";
|
2016-02-09 20:00:50 +01:00
|
|
|
ANALYZE "S 1"."T 3";
|
|
|
|
ANALYZE "S 1"."T 4";
|
2013-02-21 11:26:23 +01:00
|
|
|
|
|
|
|
-- ===================================================================
|
|
|
|
-- create foreign tables
|
|
|
|
-- ===================================================================
|
|
|
|
CREATE FOREIGN TABLE ft1 (
|
|
|
|
c0 int,
|
|
|
|
c1 int NOT NULL,
|
|
|
|
c2 int NOT NULL,
|
|
|
|
c3 text,
|
|
|
|
c4 timestamptz,
|
|
|
|
c5 timestamp,
|
|
|
|
c6 varchar(10),
|
2013-03-12 23:58:13 +01:00
|
|
|
c7 char(10) default 'ft1',
|
2013-02-21 11:26:23 +01:00
|
|
|
c8 user_enum
|
|
|
|
) SERVER loopback;
|
|
|
|
ALTER FOREIGN TABLE ft1 DROP COLUMN c0;
|
|
|
|
|
|
|
|
CREATE FOREIGN TABLE ft2 (
|
|
|
|
c1 int NOT NULL,
|
|
|
|
c2 int NOT NULL,
|
2013-03-12 23:58:13 +01:00
|
|
|
cx int,
|
2013-02-21 11:26:23 +01:00
|
|
|
c3 text,
|
|
|
|
c4 timestamptz,
|
|
|
|
c5 timestamp,
|
|
|
|
c6 varchar(10),
|
2013-03-12 23:58:13 +01:00
|
|
|
c7 char(10) default 'ft2',
|
2013-02-21 11:26:23 +01:00
|
|
|
c8 user_enum
|
|
|
|
) SERVER loopback;
|
2013-03-12 23:58:13 +01:00
|
|
|
ALTER FOREIGN TABLE ft2 DROP COLUMN cx;
|
2013-02-21 11:26:23 +01:00
|
|
|
|
2016-02-09 20:00:50 +01:00
|
|
|
CREATE FOREIGN TABLE ft4 (
|
|
|
|
c1 int NOT NULL,
|
|
|
|
c2 int NOT NULL,
|
|
|
|
c3 text
|
|
|
|
) SERVER loopback OPTIONS (schema_name 'S 1', table_name 'T 3');
|
|
|
|
|
|
|
|
CREATE FOREIGN TABLE ft5 (
|
|
|
|
c1 int NOT NULL,
|
|
|
|
c2 int NOT NULL,
|
|
|
|
c3 text
|
|
|
|
) SERVER loopback OPTIONS (schema_name 'S 1', table_name 'T 4');
|
|
|
|
|
|
|
|
CREATE FOREIGN TABLE ft6 (
|
|
|
|
c1 int NOT NULL,
|
|
|
|
c2 int NOT NULL,
|
|
|
|
c3 text
|
|
|
|
) SERVER loopback2 OPTIONS (schema_name 'S 1', table_name 'T 4');
|
|
|
|
|
2021-01-18 07:11:08 +01:00
|
|
|
CREATE FOREIGN TABLE ft7 (
|
|
|
|
c1 int NOT NULL,
|
|
|
|
c2 int NOT NULL,
|
|
|
|
c3 text
|
|
|
|
) SERVER loopback3 OPTIONS (schema_name 'S 1', table_name 'T 4');
|
|
|
|
|
2013-02-21 11:26:23 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- tests for validator
|
|
|
|
-- ===================================================================
|
2019-12-20 21:34:07 +01:00
|
|
|
-- requiressl and some other parameters are omitted because
|
|
|
|
-- valid values for them depend on configure options
|
2013-02-21 11:26:23 +01:00
|
|
|
ALTER SERVER testserver1 OPTIONS (
|
2013-02-23 18:20:48 +01:00
|
|
|
use_remote_estimate 'false',
|
2013-06-12 23:52:54 +02:00
|
|
|
updatable 'true',
|
2013-02-21 11:26:23 +01:00
|
|
|
fdw_startup_cost '123.456',
|
|
|
|
fdw_tuple_cost '0.123',
|
|
|
|
service 'value',
|
|
|
|
connect_timeout 'value',
|
|
|
|
dbname 'value',
|
|
|
|
host 'value',
|
|
|
|
hostaddr 'value',
|
|
|
|
port 'value',
|
|
|
|
--client_encoding 'value',
|
|
|
|
application_name 'value',
|
|
|
|
--fallback_application_name 'value',
|
|
|
|
keepalives 'value',
|
|
|
|
keepalives_idle 'value',
|
|
|
|
keepalives_interval 'value',
|
Add support TCP user timeout in libpq and the backend server
Similarly to the set of parameters for keepalive, a connection parameter
for libpq is added as well as a backend GUC, called tcp_user_timeout.
Increasing the TCP user timeout is useful to allow a connection to
survive extended periods without end-to-end connection, and decreasing
it allows application to fail faster. By default, the parameter is 0,
which makes the connection use the system default, and follows a logic
close to the keepalive parameters in its handling. When connecting
through a Unix-socket domain, the parameters have no effect.
Author: Ryohei Nagaura
Reviewed-by: Fabien Coelho, Robert Haas, Kyotaro Horiguchi, Kirk
Jamison, Mikalai Keida, Takayuki Tsunakawa, Andrei Yahorau
Discussion: https://postgr.es/m/EDA4195584F5064680D8130B1CA91C45367328@G01JPEXMBYT04
2019-04-06 08:23:37 +02:00
|
|
|
tcp_user_timeout 'value',
|
2013-02-21 11:26:23 +01:00
|
|
|
-- requiressl 'value',
|
2021-03-10 01:35:42 +01:00
|
|
|
sslcompression 'value',
|
2013-02-21 11:26:23 +01:00
|
|
|
sslmode 'value',
|
|
|
|
sslcert 'value',
|
|
|
|
sslkey 'value',
|
|
|
|
sslrootcert 'value',
|
2019-12-20 21:34:07 +01:00
|
|
|
sslcrl 'value',
|
2013-02-21 11:26:23 +01:00
|
|
|
--requirepeer 'value',
|
2019-12-20 21:34:07 +01:00
|
|
|
krbsrvname 'value',
|
2023-04-13 14:55:07 +02:00
|
|
|
gsslib 'value',
|
|
|
|
gssdeleg 'value'
|
2013-02-21 11:26:23 +01:00
|
|
|
--replication 'value'
|
|
|
|
);
|
2015-11-04 18:03:30 +01:00
|
|
|
|
|
|
|
-- Error, invalid list syntax
|
|
|
|
ALTER SERVER testserver1 OPTIONS (ADD extensions 'foo; bar');
|
|
|
|
|
|
|
|
-- OK but gets a warning
|
|
|
|
ALTER SERVER testserver1 OPTIONS (ADD extensions 'foo, bar');
|
|
|
|
ALTER SERVER testserver1 OPTIONS (DROP extensions);
|
|
|
|
|
2013-02-21 11:26:23 +01:00
|
|
|
ALTER USER MAPPING FOR public SERVER testserver1
|
|
|
|
OPTIONS (DROP user, DROP password);
|
2015-11-04 18:03:30 +01:00
|
|
|
|
2020-01-09 09:09:54 +01:00
|
|
|
-- Attempt to add a valid option that's not allowed in a user mapping
|
|
|
|
ALTER USER MAPPING FOR public SERVER testserver1
|
|
|
|
OPTIONS (ADD sslmode 'require');
|
|
|
|
|
|
|
|
-- But we can add valid ones fine
|
|
|
|
ALTER USER MAPPING FOR public SERVER testserver1
|
|
|
|
OPTIONS (ADD sslpassword 'dummy');
|
|
|
|
|
|
|
|
-- Ensure valid options we haven't used in a user mapping yet are
|
|
|
|
-- permitted to check validation.
|
|
|
|
ALTER USER MAPPING FOR public SERVER testserver1
|
|
|
|
OPTIONS (ADD sslkey 'value', ADD sslcert 'value');
|
|
|
|
|
2013-02-21 11:26:23 +01:00
|
|
|
ALTER FOREIGN TABLE ft1 OPTIONS (schema_name 'S 1', table_name 'T 1');
|
|
|
|
ALTER FOREIGN TABLE ft2 OPTIONS (schema_name 'S 1', table_name 'T 1');
|
|
|
|
ALTER FOREIGN TABLE ft1 ALTER COLUMN c1 OPTIONS (column_name 'C 1');
|
|
|
|
ALTER FOREIGN TABLE ft2 ALTER COLUMN c1 OPTIONS (column_name 'C 1');
|
|
|
|
\det+
|
|
|
|
|
2017-07-21 18:51:38 +02:00
|
|
|
-- Test that alteration of server options causes reconnection
|
2017-07-21 20:20:43 +02:00
|
|
|
-- Remote's errors might be non-English, so hide them to ensure stable results
|
|
|
|
\set VERBOSITY terse
|
2017-07-21 18:51:38 +02:00
|
|
|
SELECT c3, c4 FROM ft1 ORDER BY c3, c1 LIMIT 1; -- should work
|
|
|
|
ALTER SERVER loopback OPTIONS (SET dbname 'no such database');
|
|
|
|
SELECT c3, c4 FROM ft1 ORDER BY c3, c1 LIMIT 1; -- should fail
|
|
|
|
DO $d$
|
|
|
|
BEGIN
|
|
|
|
EXECUTE $$ALTER SERVER loopback
|
|
|
|
OPTIONS (SET dbname '$$||current_database()||$$')$$;
|
|
|
|
END;
|
|
|
|
$d$;
|
|
|
|
SELECT c3, c4 FROM ft1 ORDER BY c3, c1 LIMIT 1; -- should work again
|
|
|
|
|
|
|
|
-- Test that alteration of user mapping options causes reconnection
|
|
|
|
ALTER USER MAPPING FOR CURRENT_USER SERVER loopback
|
|
|
|
OPTIONS (ADD user 'no such user');
|
|
|
|
SELECT c3, c4 FROM ft1 ORDER BY c3, c1 LIMIT 1; -- should fail
|
|
|
|
ALTER USER MAPPING FOR CURRENT_USER SERVER loopback
|
|
|
|
OPTIONS (DROP user);
|
|
|
|
SELECT c3, c4 FROM ft1 ORDER BY c3, c1 LIMIT 1; -- should work again
|
2017-07-21 20:20:43 +02:00
|
|
|
\set VERBOSITY default
|
2017-07-21 18:51:38 +02:00
|
|
|
|
2013-02-21 11:26:23 +01:00
|
|
|
-- Now we should be able to run ANALYZE.
|
|
|
|
-- To exercise multiple code paths, we use local stats on ft1
|
2013-02-23 18:20:48 +01:00
|
|
|
-- and remote-estimate mode on ft2.
|
2013-02-21 11:26:23 +01:00
|
|
|
ANALYZE ft1;
|
2013-02-23 18:20:48 +01:00
|
|
|
ALTER FOREIGN TABLE ft2 OPTIONS (use_remote_estimate 'true');
|
2013-02-21 11:26:23 +01:00
|
|
|
|
|
|
|
-- ===================================================================
|
2021-11-17 14:40:38 +01:00
|
|
|
-- test error case for create publication on foreign table
|
|
|
|
-- ===================================================================
|
|
|
|
CREATE PUBLICATION testpub_ftbl FOR TABLE ft1; -- should fail
|
|
|
|
|
|
|
|
-- ===================================================================
|
2013-02-21 11:26:23 +01:00
|
|
|
-- simple queries
|
|
|
|
-- ===================================================================
|
2015-11-03 18:46:06 +01:00
|
|
|
-- single table without alias
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (COSTS OFF) SELECT * FROM ft1 ORDER BY c3, c1 OFFSET 100 LIMIT 10;
|
2013-02-21 11:26:23 +01:00
|
|
|
SELECT * FROM ft1 ORDER BY c3, c1 OFFSET 100 LIMIT 10;
|
2015-11-03 18:46:06 +01:00
|
|
|
-- single table with alias - also test that tableoid sort is not pushed to remote side
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 ORDER BY t1.c3, t1.c1, t1.tableoid OFFSET 100 LIMIT 10;
|
2015-11-03 18:46:06 +01:00
|
|
|
SELECT * FROM ft1 t1 ORDER BY t1.c3, t1.c1, t1.tableoid OFFSET 100 LIMIT 10;
|
2013-02-22 15:21:50 +01:00
|
|
|
-- whole-row reference
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT t1 FROM ft1 t1 ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10;
|
2013-02-22 15:21:50 +01:00
|
|
|
SELECT t1 FROM ft1 t1 ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10;
|
2013-02-21 11:26:23 +01:00
|
|
|
-- empty result
|
|
|
|
SELECT * FROM ft1 WHERE false;
|
|
|
|
-- with WHERE clause
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE t1.c1 = 101 AND t1.c6 = '1' AND t1.c7 >= '1';
|
2013-02-21 11:26:23 +01:00
|
|
|
SELECT * FROM ft1 t1 WHERE t1.c1 = 101 AND t1.c6 = '1' AND t1.c7 >= '1';
|
2014-12-12 18:41:49 +01:00
|
|
|
-- with FOR UPDATE/SHARE
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE c1 = 101 FOR UPDATE;
|
2014-12-12 18:41:49 +01:00
|
|
|
SELECT * FROM ft1 t1 WHERE c1 = 101 FOR UPDATE;
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE c1 = 102 FOR SHARE;
|
2014-12-12 18:41:49 +01:00
|
|
|
SELECT * FROM ft1 t1 WHERE c1 = 102 FOR SHARE;
|
2013-02-21 11:26:23 +01:00
|
|
|
-- aggregate
|
|
|
|
SELECT COUNT(*) FROM ft1 t1;
|
|
|
|
-- subquery
|
|
|
|
SELECT * FROM ft1 t1 WHERE t1.c3 IN (SELECT c3 FROM ft2 t2 WHERE c1 <= 10) ORDER BY c1;
|
|
|
|
-- subquery+MAX
|
|
|
|
SELECT * FROM ft1 t1 WHERE t1.c3 = (SELECT MAX(c3) FROM ft2 t2) ORDER BY c1;
|
|
|
|
-- used in CTE
|
|
|
|
WITH t1 AS (SELECT * FROM ft1 WHERE c1 <= 10) SELECT t2.c1, t2.c2, t2.c3, t2.c4 FROM t1, ft2 t2 WHERE t1.c1 = t2.c1 ORDER BY t1.c1;
|
|
|
|
-- fixed values
|
|
|
|
SELECT 'fixed', NULL FROM ft1 t1 WHERE c1 = 1;
|
2015-12-22 19:46:40 +01:00
|
|
|
-- Test forcing the remote server to produce sorted data for a merge join.
|
|
|
|
SET enable_hashjoin TO false;
|
|
|
|
SET enable_nestloop TO false;
|
|
|
|
-- inner join; expressions in the clauses appear in the equivalence class list
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2015-12-22 19:46:40 +01:00
|
|
|
SELECT t1.c1, t2."C 1" FROM ft2 t1 JOIN "S 1"."T 1" t2 ON (t1.c1 = t2."C 1") OFFSET 100 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2."C 1" FROM ft2 t1 JOIN "S 1"."T 1" t2 ON (t1.c1 = t2."C 1") OFFSET 100 LIMIT 10;
|
|
|
|
-- outer join; expressions in the clauses do not appear in equivalence class
|
|
|
|
-- list but no output change as compared to the previous query
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2015-12-22 19:46:40 +01:00
|
|
|
SELECT t1.c1, t2."C 1" FROM ft2 t1 LEFT JOIN "S 1"."T 1" t2 ON (t1.c1 = t2."C 1") OFFSET 100 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2."C 1" FROM ft2 t1 LEFT JOIN "S 1"."T 1" t2 ON (t1.c1 = t2."C 1") OFFSET 100 LIMIT 10;
|
2016-03-09 16:51:49 +01:00
|
|
|
-- A join between local table and foreign join. ORDER BY clause is added to the
|
|
|
|
-- foreign join so that the local table can be joined using merge join strategy.
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-03-09 16:51:49 +01:00
|
|
|
SELECT t1."C 1" FROM "S 1"."T 1" t1 left join ft1 t2 join ft2 t3 on (t2.c1 = t3.c1) on (t3.c1 = t1."C 1") OFFSET 100 LIMIT 10;
|
|
|
|
SELECT t1."C 1" FROM "S 1"."T 1" t1 left join ft1 t2 join ft2 t3 on (t2.c1 = t3.c1) on (t3.c1 = t1."C 1") OFFSET 100 LIMIT 10;
|
2016-05-16 17:28:28 +02:00
|
|
|
-- Test similar to above, except that the full join prevents any equivalence
|
|
|
|
-- classes from being merged. This produces single relation equivalence classes
|
|
|
|
-- included in join restrictions.
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-05-16 17:28:28 +02:00
|
|
|
SELECT t1."C 1", t2.c1, t3.c1 FROM "S 1"."T 1" t1 left join ft1 t2 full join ft2 t3 on (t2.c1 = t3.c1) on (t3.c1 = t1."C 1") OFFSET 100 LIMIT 10;
|
|
|
|
SELECT t1."C 1", t2.c1, t3.c1 FROM "S 1"."T 1" t1 left join ft1 t2 full join ft2 t3 on (t2.c1 = t3.c1) on (t3.c1 = t1."C 1") OFFSET 100 LIMIT 10;
|
|
|
|
-- Test similar to above with all full outer joins
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-05-16 17:28:28 +02:00
|
|
|
SELECT t1."C 1", t2.c1, t3.c1 FROM "S 1"."T 1" t1 full join ft1 t2 full join ft2 t3 on (t2.c1 = t3.c1) on (t3.c1 = t1."C 1") OFFSET 100 LIMIT 10;
|
|
|
|
SELECT t1."C 1", t2.c1, t3.c1 FROM "S 1"."T 1" t1 full join ft1 t2 full join ft2 t3 on (t2.c1 = t3.c1) on (t3.c1 = t1."C 1") OFFSET 100 LIMIT 10;
|
2015-12-22 19:46:40 +01:00
|
|
|
RESET enable_hashjoin;
|
|
|
|
RESET enable_nestloop;
|
2013-02-21 11:26:23 +01:00
|
|
|
|
2021-02-05 07:30:00 +01:00
|
|
|
-- Test executing assertion in estimate_path_cost_size() that makes sure that
|
|
|
|
-- retrieved_rows for foreign rel re-used to cost pre-sorted foreign paths is
|
|
|
|
-- a sensible value even when the rel has tuples=0
|
|
|
|
CREATE TABLE loct_empty (c1 int NOT NULL, c2 text);
|
|
|
|
CREATE FOREIGN TABLE ft_empty (c1 int NOT NULL, c2 text)
|
|
|
|
SERVER loopback OPTIONS (table_name 'loct_empty');
|
|
|
|
INSERT INTO loct_empty
|
|
|
|
SELECT id, 'AAA' || to_char(id, 'FM000') FROM generate_series(1, 100) id;
|
|
|
|
DELETE FROM loct_empty;
|
|
|
|
ANALYZE ft_empty;
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft_empty ORDER BY c1;
|
|
|
|
|
2013-02-21 11:26:23 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- WHERE with remotely-executable conditions
|
|
|
|
-- ===================================================================
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE t1.c1 = 1; -- Var, OpExpr(b), Const
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE t1.c1 = 100 AND t1.c2 = 0; -- BoolExpr
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE c1 IS NULL; -- NullTest
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE c1 IS NOT NULL; -- NullTest
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE round(abs(c1), 0) = 1; -- FuncExpr
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE c1 = -c1; -- OpExpr(l)
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE (c1 IS NOT NULL) IS DISTINCT FROM (c1 IS NOT NULL); -- DistinctExpr
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE c1 = ANY(ARRAY[c2, 1, c1 + 0]); -- ScalarArrayOpExpr
|
2019-07-01 03:00:23 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE c1 = (ARRAY[c1,c2,3])[1]; -- SubscriptingRef
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE c6 = E'foo''s\\bar'; -- check special chars
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 t1 WHERE c8 = 'foo'; -- can't be sent to remote
|
2016-02-09 20:00:50 +01:00
|
|
|
-- parameterized remote path for foreign table
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT * FROM "S 1"."T 1" a, ft2 b WHERE a."C 1" = 47 AND b.c1 = a.c2;
|
2013-03-22 00:43:59 +01:00
|
|
|
SELECT * FROM ft2 a, ft2 b WHERE a.c1 = 47 AND b.c1 = a.c2;
|
2016-02-09 20:00:50 +01:00
|
|
|
|
2014-03-07 22:35:58 +01:00
|
|
|
-- check both safe and unsafe join conditions
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2014-03-07 22:35:58 +01:00
|
|
|
SELECT * FROM ft2 a, ft2 b
|
|
|
|
WHERE a.c2 = 6 AND b.c1 = a.c1 AND a.c8 = 'foo' AND b.c7 = upper(a.c7);
|
|
|
|
SELECT * FROM ft2 a, ft2 b
|
|
|
|
WHERE a.c2 = 6 AND b.c1 = a.c1 AND a.c8 = 'foo' AND b.c7 = upper(a.c7);
|
2014-04-16 23:21:57 +02:00
|
|
|
-- bug before 9.3.5 due to sloppy handling of remote-estimate parameters
|
|
|
|
SELECT * FROM ft1 WHERE c1 = ANY (ARRAY(SELECT c1 FROM ft2 WHERE c1 < 5));
|
|
|
|
SELECT * FROM ft2 WHERE c1 = ANY (ARRAY(SELECT c1 FROM ft1 WHERE c1 < 5));
|
2015-11-03 18:46:06 +01:00
|
|
|
-- we should not push order by clause with volatile expressions or unsafe
|
|
|
|
-- collations
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2015-11-03 18:46:06 +01:00
|
|
|
SELECT * FROM ft2 ORDER BY ft2.c1, random();
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2015-11-03 18:46:06 +01:00
|
|
|
SELECT * FROM ft2 ORDER BY ft2.c1, ft2.c3 collate "C";
|
2013-02-21 11:26:23 +01:00
|
|
|
|
2015-11-04 18:03:30 +01:00
|
|
|
-- user-defined operator/function
|
|
|
|
CREATE FUNCTION postgres_fdw_abs(int) RETURNS int AS $$
|
|
|
|
BEGIN
|
|
|
|
RETURN abs($1);
|
|
|
|
END
|
|
|
|
$$ LANGUAGE plpgsql IMMUTABLE;
|
|
|
|
CREATE OPERATOR === (
|
|
|
|
LEFTARG = int,
|
|
|
|
RIGHTARG = int,
|
|
|
|
PROCEDURE = int4eq,
|
|
|
|
COMMUTATOR = ===
|
|
|
|
);
|
|
|
|
|
|
|
|
-- built-in operators and functions can be shipped for remote execution
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2015-11-04 18:03:30 +01:00
|
|
|
SELECT count(c3) FROM ft1 t1 WHERE t1.c1 = abs(t1.c2);
|
|
|
|
SELECT count(c3) FROM ft1 t1 WHERE t1.c1 = abs(t1.c2);
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2015-11-04 18:03:30 +01:00
|
|
|
SELECT count(c3) FROM ft1 t1 WHERE t1.c1 = t1.c2;
|
|
|
|
SELECT count(c3) FROM ft1 t1 WHERE t1.c1 = t1.c2;
|
|
|
|
|
|
|
|
-- by default, user-defined ones cannot
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2015-11-04 18:03:30 +01:00
|
|
|
SELECT count(c3) FROM ft1 t1 WHERE t1.c1 = postgres_fdw_abs(t1.c2);
|
|
|
|
SELECT count(c3) FROM ft1 t1 WHERE t1.c1 = postgres_fdw_abs(t1.c2);
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2015-11-04 18:03:30 +01:00
|
|
|
SELECT count(c3) FROM ft1 t1 WHERE t1.c1 === t1.c2;
|
|
|
|
SELECT count(c3) FROM ft1 t1 WHERE t1.c1 === t1.c2;
|
|
|
|
|
2019-04-02 13:30:45 +02:00
|
|
|
-- ORDER BY can be shipped, though
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM ft1 t1 WHERE t1.c1 === t1.c2 order by t1.c2 limit 1;
|
|
|
|
SELECT * FROM ft1 t1 WHERE t1.c1 === t1.c2 order by t1.c2 limit 1;
|
|
|
|
|
2015-11-04 18:03:30 +01:00
|
|
|
-- but let's put them in an extension ...
|
|
|
|
ALTER EXTENSION postgres_fdw ADD FUNCTION postgres_fdw_abs(int);
|
|
|
|
ALTER EXTENSION postgres_fdw ADD OPERATOR === (int, int);
|
|
|
|
ALTER SERVER loopback OPTIONS (ADD extensions 'postgres_fdw');
|
|
|
|
|
|
|
|
-- ... now they can be shipped
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2015-11-04 18:03:30 +01:00
|
|
|
SELECT count(c3) FROM ft1 t1 WHERE t1.c1 = postgres_fdw_abs(t1.c2);
|
|
|
|
SELECT count(c3) FROM ft1 t1 WHERE t1.c1 = postgres_fdw_abs(t1.c2);
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2015-11-04 18:03:30 +01:00
|
|
|
SELECT count(c3) FROM ft1 t1 WHERE t1.c1 === t1.c2;
|
|
|
|
SELECT count(c3) FROM ft1 t1 WHERE t1.c1 === t1.c2;
|
|
|
|
|
2019-04-02 13:30:45 +02:00
|
|
|
-- and both ORDER BY and LIMIT can be shipped
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM ft1 t1 WHERE t1.c1 === t1.c2 order by t1.c2 limit 1;
|
|
|
|
SELECT * FROM ft1 t1 WHERE t1.c1 === t1.c2 order by t1.c2 limit 1;
|
|
|
|
|
2021-07-30 19:39:48 +02:00
|
|
|
-- Test CASE pushdown
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT c1,c2,c3 FROM ft2 WHERE CASE WHEN c1 > 990 THEN c1 END < 1000 ORDER BY c1;
|
|
|
|
SELECT c1,c2,c3 FROM ft2 WHERE CASE WHEN c1 > 990 THEN c1 END < 1000 ORDER BY c1;
|
|
|
|
|
|
|
|
-- Nested CASE
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT c1,c2,c3 FROM ft2 WHERE CASE CASE WHEN c2 > 0 THEN c2 END WHEN 100 THEN 601 WHEN c2 THEN c2 ELSE 0 END > 600 ORDER BY c1;
|
|
|
|
|
|
|
|
SELECT c1,c2,c3 FROM ft2 WHERE CASE CASE WHEN c2 > 0 THEN c2 END WHEN 100 THEN 601 WHEN c2 THEN c2 ELSE 0 END > 600 ORDER BY c1;
|
|
|
|
|
|
|
|
-- CASE arg WHEN
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM ft1 WHERE c1 > (CASE mod(c1, 4) WHEN 0 THEN 1 WHEN 2 THEN 50 ELSE 100 END);
|
|
|
|
|
|
|
|
-- CASE cannot be pushed down because of unshippable arg clause
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM ft1 WHERE c1 > (CASE random()::integer WHEN 0 THEN 1 WHEN 2 THEN 50 ELSE 100 END);
|
|
|
|
|
|
|
|
-- these are shippable
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM ft1 WHERE CASE c6 WHEN 'foo' THEN true ELSE c3 < 'bar' END;
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM ft1 WHERE CASE c3 WHEN c6 THEN true ELSE c3 < 'bar' END;
|
|
|
|
|
|
|
|
-- but this is not because of collation
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM ft1 WHERE CASE c3 COLLATE "C" WHEN c6 THEN true ELSE c3 < 'bar' END;
|
|
|
|
|
2022-07-18 00:11:22 +02:00
|
|
|
-- a regconfig constant referring to this text search configuration
|
|
|
|
-- is initially unshippable
|
2022-07-17 23:27:50 +02:00
|
|
|
CREATE TEXT SEARCH CONFIGURATION public.custom_search
|
|
|
|
(COPY = pg_catalog.english);
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT c1, to_tsvector('custom_search'::regconfig, c3) FROM ft1
|
|
|
|
WHERE c1 = 642 AND length(to_tsvector('custom_search'::regconfig, c3)) > 0;
|
|
|
|
SELECT c1, to_tsvector('custom_search'::regconfig, c3) FROM ft1
|
|
|
|
WHERE c1 = 642 AND length(to_tsvector('custom_search'::regconfig, c3)) > 0;
|
2022-07-18 00:11:22 +02:00
|
|
|
-- but if it's in a shippable extension, it can be shipped
|
|
|
|
ALTER EXTENSION postgres_fdw ADD TEXT SEARCH CONFIGURATION public.custom_search;
|
|
|
|
-- however, that doesn't flush the shippability cache, so do a quick reconnect
|
|
|
|
\c -
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT c1, to_tsvector('custom_search'::regconfig, c3) FROM ft1
|
|
|
|
WHERE c1 = 642 AND length(to_tsvector('custom_search'::regconfig, c3)) > 0;
|
|
|
|
SELECT c1, to_tsvector('custom_search'::regconfig, c3) FROM ft1
|
|
|
|
WHERE c1 = 642 AND length(to_tsvector('custom_search'::regconfig, c3)) > 0;
|
2022-07-17 23:27:50 +02:00
|
|
|
|
2016-02-09 20:00:50 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- JOIN queries
|
|
|
|
-- ===================================================================
|
|
|
|
-- Analyze ft4 and ft5 so that we have better statistics. These tables do not
|
|
|
|
-- have use_remote_estimate set.
|
|
|
|
ANALYZE ft4;
|
|
|
|
ANALYZE ft5;
|
|
|
|
|
|
|
|
-- join two tables
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10;
|
|
|
|
-- join three tables
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) JOIN ft4 t3 ON (t3.c1 = t1.c1) ORDER BY t1.c3, t1.c1 OFFSET 10 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) JOIN ft4 t3 ON (t3.c1 = t1.c1) ORDER BY t1.c3, t1.c1 OFFSET 10 LIMIT 10;
|
|
|
|
-- left outer join
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c1 FROM ft4 t1 LEFT JOIN ft5 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 10 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c1 FROM ft4 t1 LEFT JOIN ft5 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 10 LIMIT 10;
|
2016-03-23 17:28:01 +01:00
|
|
|
-- left outer join three tables
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-03-23 17:28:01 +01:00
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 LEFT JOIN ft2 t2 ON (t1.c1 = t2.c1) LEFT JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 LEFT JOIN ft2 t2 ON (t1.c1 = t2.c1) LEFT JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
2016-02-09 20:00:50 +01:00
|
|
|
-- left outer join + placement of clauses.
|
|
|
|
-- clauses within the nullable side are not pulled up, but top level clause on
|
|
|
|
-- non-nullable side is pushed into non-nullable side
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t1.c2, t2.c1, t2.c2 FROM ft4 t1 LEFT JOIN (SELECT * FROM ft5 WHERE c1 < 10) t2 ON (t1.c1 = t2.c1) WHERE t1.c1 < 10;
|
|
|
|
SELECT t1.c1, t1.c2, t2.c1, t2.c2 FROM ft4 t1 LEFT JOIN (SELECT * FROM ft5 WHERE c1 < 10) t2 ON (t1.c1 = t2.c1) WHERE t1.c1 < 10;
|
|
|
|
-- clauses within the nullable side are not pulled up, but the top level clause
|
|
|
|
-- on nullable side is not pushed down into nullable side
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t1.c2, t2.c1, t2.c2 FROM ft4 t1 LEFT JOIN (SELECT * FROM ft5 WHERE c1 < 10) t2 ON (t1.c1 = t2.c1)
|
|
|
|
WHERE (t2.c1 < 10 OR t2.c1 IS NULL) AND t1.c1 < 10;
|
|
|
|
SELECT t1.c1, t1.c2, t2.c1, t2.c2 FROM ft4 t1 LEFT JOIN (SELECT * FROM ft5 WHERE c1 < 10) t2 ON (t1.c1 = t2.c1)
|
|
|
|
WHERE (t2.c1 < 10 OR t2.c1 IS NULL) AND t1.c1 < 10;
|
|
|
|
-- right outer join
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c1 FROM ft5 t1 RIGHT JOIN ft4 t2 ON (t1.c1 = t2.c1) ORDER BY t2.c1, t1.c1 OFFSET 10 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c1 FROM ft5 t1 RIGHT JOIN ft4 t2 ON (t1.c1 = t2.c1) ORDER BY t2.c1, t1.c1 OFFSET 10 LIMIT 10;
|
2016-03-23 17:28:01 +01:00
|
|
|
-- right outer join three tables
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-03-23 17:28:01 +01:00
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 RIGHT JOIN ft2 t2 ON (t1.c1 = t2.c1) RIGHT JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 RIGHT JOIN ft2 t2 ON (t1.c1 = t2.c1) RIGHT JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
2016-02-09 20:00:50 +01:00
|
|
|
-- full outer join
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c1 FROM ft4 t1 FULL JOIN ft5 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 45 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c1 FROM ft4 t1 FULL JOIN ft5 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 45 LIMIT 10;
|
2016-04-21 05:34:07 +02:00
|
|
|
-- full outer join with restrictions on the joining relations
|
2017-03-16 18:34:59 +01:00
|
|
|
-- a. the joining relations are both base relations
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-04-21 05:34:07 +02:00
|
|
|
SELECT t1.c1, t2.c1 FROM (SELECT c1 FROM ft4 WHERE c1 between 50 and 60) t1 FULL JOIN (SELECT c1 FROM ft5 WHERE c1 between 50 and 60) t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1;
|
|
|
|
SELECT t1.c1, t2.c1 FROM (SELECT c1 FROM ft4 WHERE c1 between 50 and 60) t1 FULL JOIN (SELECT c1 FROM ft5 WHERE c1 between 50 and 60) t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1;
|
2017-03-16 18:34:59 +01:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT 1 FROM (SELECT c1 FROM ft4 WHERE c1 between 50 and 60) t1 FULL JOIN (SELECT c1 FROM ft5 WHERE c1 between 50 and 60) t2 ON (TRUE) OFFSET 10 LIMIT 10;
|
|
|
|
SELECT 1 FROM (SELECT c1 FROM ft4 WHERE c1 between 50 and 60) t1 FULL JOIN (SELECT c1 FROM ft5 WHERE c1 between 50 and 60) t2 ON (TRUE) OFFSET 10 LIMIT 10;
|
|
|
|
-- b. one of the joining relations is a base relation and the other is a join
|
|
|
|
-- relation
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT t1.c1, ss.a, ss.b FROM (SELECT c1 FROM ft4 WHERE c1 between 50 and 60) t1 FULL JOIN (SELECT t2.c1, t3.c1 FROM ft4 t2 LEFT JOIN ft5 t3 ON (t2.c1 = t3.c1) WHERE (t2.c1 between 50 and 60)) ss(a, b) ON (t1.c1 = ss.a) ORDER BY t1.c1, ss.a, ss.b;
|
|
|
|
SELECT t1.c1, ss.a, ss.b FROM (SELECT c1 FROM ft4 WHERE c1 between 50 and 60) t1 FULL JOIN (SELECT t2.c1, t3.c1 FROM ft4 t2 LEFT JOIN ft5 t3 ON (t2.c1 = t3.c1) WHERE (t2.c1 between 50 and 60)) ss(a, b) ON (t1.c1 = ss.a) ORDER BY t1.c1, ss.a, ss.b;
|
|
|
|
-- c. test deparsing the remote query as nested subqueries
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT t1.c1, ss.a, ss.b FROM (SELECT c1 FROM ft4 WHERE c1 between 50 and 60) t1 FULL JOIN (SELECT t2.c1, t3.c1 FROM (SELECT c1 FROM ft4 WHERE c1 between 50 and 60) t2 FULL JOIN (SELECT c1 FROM ft5 WHERE c1 between 50 and 60) t3 ON (t2.c1 = t3.c1) WHERE t2.c1 IS NULL OR t2.c1 IS NOT NULL) ss(a, b) ON (t1.c1 = ss.a) ORDER BY t1.c1, ss.a, ss.b;
|
|
|
|
SELECT t1.c1, ss.a, ss.b FROM (SELECT c1 FROM ft4 WHERE c1 between 50 and 60) t1 FULL JOIN (SELECT t2.c1, t3.c1 FROM (SELECT c1 FROM ft4 WHERE c1 between 50 and 60) t2 FULL JOIN (SELECT c1 FROM ft5 WHERE c1 between 50 and 60) t3 ON (t2.c1 = t3.c1) WHERE t2.c1 IS NULL OR t2.c1 IS NOT NULL) ss(a, b) ON (t1.c1 = ss.a) ORDER BY t1.c1, ss.a, ss.b;
|
|
|
|
-- d. test deparsing rowmarked relations as subqueries
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT t1.c1, ss.a, ss.b FROM (SELECT c1 FROM "S 1"."T 3" WHERE c1 = 50) t1 INNER JOIN (SELECT t2.c1, t3.c1 FROM (SELECT c1 FROM ft4 WHERE c1 between 50 and 60) t2 FULL JOIN (SELECT c1 FROM ft5 WHERE c1 between 50 and 60) t3 ON (t2.c1 = t3.c1) WHERE t2.c1 IS NULL OR t2.c1 IS NOT NULL) ss(a, b) ON (TRUE) ORDER BY t1.c1, ss.a, ss.b FOR UPDATE OF t1;
|
|
|
|
SELECT t1.c1, ss.a, ss.b FROM (SELECT c1 FROM "S 1"."T 3" WHERE c1 = 50) t1 INNER JOIN (SELECT t2.c1, t3.c1 FROM (SELECT c1 FROM ft4 WHERE c1 between 50 and 60) t2 FULL JOIN (SELECT c1 FROM ft5 WHERE c1 between 50 and 60) t3 ON (t2.c1 = t3.c1) WHERE t2.c1 IS NULL OR t2.c1 IS NOT NULL) ss(a, b) ON (TRUE) ORDER BY t1.c1, ss.a, ss.b FOR UPDATE OF t1;
|
2016-04-21 05:34:07 +02:00
|
|
|
-- full outer join + inner join
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-04-21 05:34:07 +02:00
|
|
|
SELECT t1.c1, t2.c1, t3.c1 FROM ft4 t1 INNER JOIN ft5 t2 ON (t1.c1 = t2.c1 + 1 and t1.c1 between 50 and 60) FULL JOIN ft4 t3 ON (t2.c1 = t3.c1) ORDER BY t1.c1, t2.c1, t3.c1 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c1, t3.c1 FROM ft4 t1 INNER JOIN ft5 t2 ON (t1.c1 = t2.c1 + 1 and t1.c1 between 50 and 60) FULL JOIN ft4 t3 ON (t2.c1 = t3.c1) ORDER BY t1.c1, t2.c1, t3.c1 LIMIT 10;
|
2016-03-23 17:28:01 +01:00
|
|
|
-- full outer join three tables
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-03-23 17:28:01 +01:00
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 FULL JOIN ft2 t2 ON (t1.c1 = t2.c1) FULL JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 FULL JOIN ft2 t2 ON (t1.c1 = t2.c1) FULL JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
|
|
|
-- full outer join + right outer join
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-03-23 17:28:01 +01:00
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 FULL JOIN ft2 t2 ON (t1.c1 = t2.c1) RIGHT JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 FULL JOIN ft2 t2 ON (t1.c1 = t2.c1) RIGHT JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
|
|
|
-- right outer join + full outer join
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-03-23 17:28:01 +01:00
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 RIGHT JOIN ft2 t2 ON (t1.c1 = t2.c1) FULL JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 RIGHT JOIN ft2 t2 ON (t1.c1 = t2.c1) FULL JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
|
|
|
-- full outer join + left outer join
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-03-23 17:28:01 +01:00
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 FULL JOIN ft2 t2 ON (t1.c1 = t2.c1) LEFT JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 FULL JOIN ft2 t2 ON (t1.c1 = t2.c1) LEFT JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
|
|
|
-- left outer join + full outer join
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-03-23 17:28:01 +01:00
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 LEFT JOIN ft2 t2 ON (t1.c1 = t2.c1) FULL JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 LEFT JOIN ft2 t2 ON (t1.c1 = t2.c1) FULL JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
2021-07-14 02:43:58 +02:00
|
|
|
SET enable_memoize TO off;
|
2016-03-23 17:28:01 +01:00
|
|
|
-- right outer join + left outer join
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-03-23 17:28:01 +01:00
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 RIGHT JOIN ft2 t2 ON (t1.c1 = t2.c1) LEFT JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 RIGHT JOIN ft2 t2 ON (t1.c1 = t2.c1) LEFT JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
2021-07-14 02:43:58 +02:00
|
|
|
RESET enable_memoize;
|
2016-03-23 17:28:01 +01:00
|
|
|
-- left outer join + right outer join
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-03-23 17:28:01 +01:00
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 LEFT JOIN ft2 t2 ON (t1.c1 = t2.c1) RIGHT JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c2, t3.c3 FROM ft2 t1 LEFT JOIN ft2 t2 ON (t1.c1 = t2.c1) RIGHT JOIN ft4 t3 ON (t2.c1 = t3.c1) OFFSET 10 LIMIT 10;
|
2016-02-09 20:00:50 +01:00
|
|
|
-- full outer join + WHERE clause, only matched rows
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c1 FROM ft4 t1 FULL JOIN ft5 t2 ON (t1.c1 = t2.c1) WHERE (t1.c1 = t2.c1 OR t1.c1 IS NULL) ORDER BY t1.c1, t2.c1 OFFSET 10 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c1 FROM ft4 t1 FULL JOIN ft5 t2 ON (t1.c1 = t2.c1) WHERE (t1.c1 = t2.c1 OR t1.c1 IS NULL) ORDER BY t1.c1, t2.c1 OFFSET 10 LIMIT 10;
|
2017-04-25 04:50:07 +02:00
|
|
|
-- full outer join + WHERE clause with shippable extensions set
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT t1.c1, t2.c2, t1.c3 FROM ft1 t1 FULL JOIN ft2 t2 ON (t1.c1 = t2.c1) WHERE postgres_fdw_abs(t1.c1) > 0 OFFSET 10 LIMIT 10;
|
|
|
|
ALTER SERVER loopback OPTIONS (DROP extensions);
|
|
|
|
-- full outer join + WHERE clause with shippable extensions not set
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT t1.c1, t2.c2, t1.c3 FROM ft1 t1 FULL JOIN ft2 t2 ON (t1.c1 = t2.c1) WHERE postgres_fdw_abs(t1.c1) > 0 OFFSET 10 LIMIT 10;
|
|
|
|
ALTER SERVER loopback OPTIONS (ADD extensions 'postgres_fdw');
|
2016-02-09 20:00:50 +01:00
|
|
|
-- join two tables with FOR UPDATE clause
|
|
|
|
-- tests whole-row reference for row marks
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10 FOR UPDATE OF t1;
|
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10 FOR UPDATE OF t1;
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10 FOR UPDATE;
|
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10 FOR UPDATE;
|
|
|
|
-- join two tables with FOR SHARE clause
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10 FOR SHARE OF t1;
|
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10 FOR SHARE OF t1;
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10 FOR SHARE;
|
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10 FOR SHARE;
|
|
|
|
-- join in CTE
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
Allow user control of CTE materialization, and change the default behavior.
Historically we've always materialized the full output of a CTE query,
treating WITH as an optimization fence (so that, for example, restrictions
from the outer query cannot be pushed into it). This is appropriate when
the CTE query is INSERT/UPDATE/DELETE, or is recursive; but when the CTE
query is non-recursive and side-effect-free, there's no hazard of changing
the query results by pushing restrictions down.
Another argument for materialization is that it can avoid duplicate
computation of an expensive WITH query --- but that only applies if
the WITH query is called more than once in the outer query. Even then
it could still be a net loss, if each call has restrictions that
would allow just a small part of the WITH query to be computed.
Hence, let's change the behavior for WITH queries that are non-recursive
and side-effect-free. By default, we will inline them into the outer
query (removing the optimization fence) if they are called just once.
If they are called more than once, we will keep the old behavior by
default, but the user can override this and force inlining by specifying
NOT MATERIALIZED. Lastly, the user can force the old behavior by
specifying MATERIALIZED; this would mainly be useful when the query had
deliberately been employing WITH as an optimization fence to prevent a
poor choice of plan.
Andreas Karlsson, Andrew Gierth, David Fetter
Discussion: https://postgr.es/m/87sh48ffhb.fsf@news-spur.riddles.org.uk
2019-02-16 22:11:12 +01:00
|
|
|
WITH t (c1_1, c1_3, c2_1) AS MATERIALIZED (SELECT t1.c1, t1.c3, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1)) SELECT c1_1, c2_1 FROM t ORDER BY c1_3, c1_1 OFFSET 100 LIMIT 10;
|
|
|
|
WITH t (c1_1, c1_3, c2_1) AS MATERIALIZED (SELECT t1.c1, t1.c3, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1)) SELECT c1_1, c2_1 FROM t ORDER BY c1_3, c1_1 OFFSET 100 LIMIT 10;
|
2016-02-09 20:00:50 +01:00
|
|
|
-- ctid with whole-row reference
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.ctid, t1, t2, t1.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10;
|
|
|
|
-- SEMI JOIN, not pushed down
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1 FROM ft1 t1 WHERE EXISTS (SELECT 1 FROM ft2 t2 WHERE t1.c1 = t2.c1) ORDER BY t1.c1 OFFSET 100 LIMIT 10;
|
|
|
|
SELECT t1.c1 FROM ft1 t1 WHERE EXISTS (SELECT 1 FROM ft2 t2 WHERE t1.c1 = t2.c1) ORDER BY t1.c1 OFFSET 100 LIMIT 10;
|
|
|
|
-- ANTI JOIN, not pushed down
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1 FROM ft1 t1 WHERE NOT EXISTS (SELECT 1 FROM ft2 t2 WHERE t1.c1 = t2.c2) ORDER BY t1.c1 OFFSET 100 LIMIT 10;
|
|
|
|
SELECT t1.c1 FROM ft1 t1 WHERE NOT EXISTS (SELECT 1 FROM ft2 t2 WHERE t1.c1 = t2.c2) ORDER BY t1.c1 OFFSET 100 LIMIT 10;
|
2019-04-02 13:30:45 +02:00
|
|
|
-- CROSS JOIN can be pushed down
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 CROSS JOIN ft2 t2 ORDER BY t1.c1, t2.c1 OFFSET 100 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 CROSS JOIN ft2 t2 ORDER BY t1.c1, t2.c1 OFFSET 100 LIMIT 10;
|
|
|
|
-- different server, not pushed down. No result expected.
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c1 FROM ft5 t1 JOIN ft6 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 100 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c1 FROM ft5 t1 JOIN ft6 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 100 LIMIT 10;
|
|
|
|
-- unsafe join conditions (c8 has a UDT), not pushed down. Practically a CROSS
|
|
|
|
-- JOIN since c8 in both tables has same value.
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 LEFT JOIN ft2 t2 ON (t1.c8 = t2.c8) ORDER BY t1.c1, t2.c1 OFFSET 100 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 LEFT JOIN ft2 t2 ON (t1.c8 = t2.c8) ORDER BY t1.c1, t2.c1 OFFSET 100 LIMIT 10;
|
|
|
|
-- unsafe conditions on one side (c8 has a UDT), not pushed down.
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 LEFT JOIN ft2 t2 ON (t1.c1 = t2.c1) WHERE t1.c8 = 'foo' ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 LEFT JOIN ft2 t2 ON (t1.c1 = t2.c1) WHERE t1.c8 = 'foo' ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10;
|
|
|
|
-- join where unsafe to pushdown condition in WHERE clause has a column not
|
|
|
|
-- in the SELECT clause. In this test unsafe clause needs to have column
|
|
|
|
-- references from both joining sides so that the clause is not pushed down
|
|
|
|
-- into one of the joining sides.
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) WHERE t1.c8 = t2.c8 ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10;
|
|
|
|
SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) WHERE t1.c8 = t2.c8 ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10;
|
|
|
|
-- Aggregate after UNION, for testing setrefs
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1c1, avg(t1c1 + t2c1) FROM (SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) UNION SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1)) AS t (t1c1, t2c1) GROUP BY t1c1 ORDER BY t1c1 OFFSET 100 LIMIT 10;
|
|
|
|
SELECT t1c1, avg(t1c1 + t2c1) FROM (SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1) UNION SELECT t1.c1, t2.c1 FROM ft1 t1 JOIN ft2 t2 ON (t1.c1 = t2.c1)) AS t (t1c1, t2c1) GROUP BY t1c1 ORDER BY t1c1 OFFSET 100 LIMIT 10;
|
|
|
|
-- join with lateral reference
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-02-09 20:00:50 +01:00
|
|
|
SELECT t1."C 1" FROM "S 1"."T 1" t1, LATERAL (SELECT DISTINCT t2.c1, t3.c1 FROM ft1 t2, ft2 t3 WHERE t2.c1 = t3.c1 AND t2.c2 = t1.c2) q ORDER BY t1."C 1" OFFSET 10 LIMIT 10;
|
|
|
|
SELECT t1."C 1" FROM "S 1"."T 1" t1, LATERAL (SELECT DISTINCT t2.c1, t3.c1 FROM ft1 t2, ft2 t3 WHERE t2.c1 = t3.c1 AND t2.c2 = t1.c2) q ORDER BY t1."C 1" OFFSET 10 LIMIT 10;
|
|
|
|
|
2017-02-06 10:33:58 +01:00
|
|
|
-- non-Var items in targetlist of the nullable rel of a join preventing
|
2016-06-14 17:48:27 +02:00
|
|
|
-- push-down in some cases
|
|
|
|
-- unable to push {ft1, ft2}
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-06-14 17:48:27 +02:00
|
|
|
SELECT q.a, ft2.c1 FROM (SELECT 13 FROM ft1 WHERE c1 = 13) q(a) RIGHT JOIN ft2 ON (q.a = ft2.c1) WHERE ft2.c1 BETWEEN 10 AND 15;
|
|
|
|
SELECT q.a, ft2.c1 FROM (SELECT 13 FROM ft1 WHERE c1 = 13) q(a) RIGHT JOIN ft2 ON (q.a = ft2.c1) WHERE ft2.c1 BETWEEN 10 AND 15;
|
|
|
|
|
|
|
|
-- ok to push {ft1, ft2} but not {ft1, ft2, ft4}
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2016-06-14 17:48:27 +02:00
|
|
|
SELECT ft4.c1, q.* FROM ft4 LEFT JOIN (SELECT 13, ft1.c1, ft2.c1 FROM ft1 RIGHT JOIN ft2 ON (ft1.c1 = ft2.c1) WHERE ft1.c1 = 12) q(a, b, c) ON (ft4.c1 = q.b) WHERE ft4.c1 BETWEEN 10 AND 15;
|
|
|
|
SELECT ft4.c1, q.* FROM ft4 LEFT JOIN (SELECT 13, ft1.c1, ft2.c1 FROM ft1 RIGHT JOIN ft2 ON (ft1.c1 = ft2.c1) WHERE ft1.c1 = 12) q(a, b, c) ON (ft4.c1 = q.b) WHERE ft4.c1 BETWEEN 10 AND 15;
|
|
|
|
|
2016-06-24 21:06:19 +02:00
|
|
|
-- join with nullable side with some columns with null values
|
|
|
|
UPDATE ft5 SET c3 = null where c1 % 9 = 0;
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT ft5, ft5.c1, ft5.c2, ft5.c3, ft4.c1, ft4.c2 FROM ft5 left join ft4 on ft5.c1 = ft4.c1 WHERE ft4.c1 BETWEEN 10 and 30 ORDER BY ft5.c1, ft4.c1;
|
2016-06-24 21:06:19 +02:00
|
|
|
SELECT ft5, ft5.c1, ft5.c2, ft5.c3, ft4.c1, ft4.c2 FROM ft5 left join ft4 on ft5.c1 = ft4.c1 WHERE ft4.c1 BETWEEN 10 and 30 ORDER BY ft5.c1, ft4.c1;
|
|
|
|
|
2018-01-17 22:18:39 +01:00
|
|
|
-- multi-way join involving multiple merge joins
|
2018-01-30 20:27:38 +01:00
|
|
|
-- (this case used to have EPQ-related planning problems)
|
2019-04-02 12:38:56 +02:00
|
|
|
CREATE TABLE local_tbl (c1 int NOT NULL, c2 int NOT NULL, c3 text, CONSTRAINT local_tbl_pkey PRIMARY KEY (c1));
|
|
|
|
INSERT INTO local_tbl SELECT id, id % 10, to_char(id, 'FM0000') FROM generate_series(1, 1000) id;
|
|
|
|
ANALYZE local_tbl;
|
2018-01-30 20:27:38 +01:00
|
|
|
SET enable_nestloop TO false;
|
|
|
|
SET enable_hashjoin TO false;
|
2018-01-17 22:18:39 +01:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2019-04-02 12:38:56 +02:00
|
|
|
SELECT * FROM ft1, ft2, ft4, ft5, local_tbl WHERE ft1.c1 = ft2.c1 AND ft1.c2 = ft4.c1
|
|
|
|
AND ft1.c2 = ft5.c1 AND ft1.c2 = local_tbl.c1 AND ft1.c1 < 100 AND ft2.c1 < 100 FOR UPDATE;
|
|
|
|
SELECT * FROM ft1, ft2, ft4, ft5, local_tbl WHERE ft1.c1 = ft2.c1 AND ft1.c2 = ft4.c1
|
|
|
|
AND ft1.c2 = ft5.c1 AND ft1.c2 = local_tbl.c1 AND ft1.c1 < 100 AND ft2.c1 < 100 FOR UPDATE;
|
2018-01-30 20:27:38 +01:00
|
|
|
RESET enable_nestloop;
|
|
|
|
RESET enable_hashjoin;
|
2022-09-14 11:45:00 +02:00
|
|
|
|
|
|
|
-- test that add_paths_with_pathkeys_for_rel() arranges for the epq_path to
|
|
|
|
-- return columns needed by the parent ForeignScan node
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM local_tbl LEFT JOIN (SELECT ft1.*, COALESCE(ft1.c3 || ft2.c3, 'foobar') FROM ft1 INNER JOIN ft2 ON (ft1.c1 = ft2.c1 AND ft1.c1 < 100)) ss ON (local_tbl.c1 = ss.c1) ORDER BY local_tbl.c1 FOR UPDATE OF local_tbl;
|
|
|
|
|
|
|
|
ALTER SERVER loopback OPTIONS (DROP extensions);
|
|
|
|
ALTER SERVER loopback OPTIONS (ADD fdw_startup_cost '10000.0');
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2023-01-30 19:50:25 +01:00
|
|
|
SELECT * FROM local_tbl LEFT JOIN (SELECT ft1.* FROM ft1 INNER JOIN ft2 ON (ft1.c1 = ft2.c1 AND ft1.c1 < 100 AND (ft1.c1 - postgres_fdw_abs(ft2.c2)) = 0)) ss ON (local_tbl.c3 = ss.c3) ORDER BY local_tbl.c1 FOR UPDATE OF local_tbl;
|
2022-09-14 11:45:00 +02:00
|
|
|
ALTER SERVER loopback OPTIONS (DROP fdw_startup_cost);
|
|
|
|
ALTER SERVER loopback OPTIONS (ADD extensions 'postgres_fdw');
|
|
|
|
|
2019-04-02 12:38:56 +02:00
|
|
|
DROP TABLE local_tbl;
|
2018-01-17 22:18:39 +01:00
|
|
|
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
-- check join pushdown in situations where multiple userids are involved
|
2017-12-05 19:12:00 +01:00
|
|
|
CREATE ROLE regress_view_owner SUPERUSER;
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
CREATE USER MAPPING FOR regress_view_owner SERVER loopback;
|
|
|
|
GRANT SELECT ON ft4 TO regress_view_owner;
|
|
|
|
GRANT SELECT ON ft5 TO regress_view_owner;
|
|
|
|
|
|
|
|
CREATE VIEW v4 AS SELECT * FROM ft4;
|
|
|
|
CREATE VIEW v5 AS SELECT * FROM ft5;
|
|
|
|
ALTER VIEW v5 OWNER TO regress_view_owner;
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT t1.c1, t2.c2 FROM v4 t1 LEFT JOIN v5 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 10 LIMIT 10; -- can't be pushed down, different view owners
|
|
|
|
SELECT t1.c1, t2.c2 FROM v4 t1 LEFT JOIN v5 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 10 LIMIT 10;
|
|
|
|
ALTER VIEW v4 OWNER TO regress_view_owner;
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT t1.c1, t2.c2 FROM v4 t1 LEFT JOIN v5 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 10 LIMIT 10; -- can be pushed down
|
|
|
|
SELECT t1.c1, t2.c2 FROM v4 t1 LEFT JOIN v5 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 10 LIMIT 10;
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT t1.c1, t2.c2 FROM v4 t1 LEFT JOIN ft5 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 10 LIMIT 10; -- can't be pushed down, view owner not current user
|
|
|
|
SELECT t1.c1, t2.c2 FROM v4 t1 LEFT JOIN ft5 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 10 LIMIT 10;
|
|
|
|
ALTER VIEW v4 OWNER TO CURRENT_USER;
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT t1.c1, t2.c2 FROM v4 t1 LEFT JOIN ft5 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 10 LIMIT 10; -- can be pushed down
|
|
|
|
SELECT t1.c1, t2.c2 FROM v4 t1 LEFT JOIN ft5 t2 ON (t1.c1 = t2.c1) ORDER BY t1.c1, t2.c1 OFFSET 10 LIMIT 10;
|
|
|
|
ALTER VIEW v4 OWNER TO regress_view_owner;
|
|
|
|
|
|
|
|
-- cleanup
|
|
|
|
DROP OWNED BY regress_view_owner;
|
|
|
|
DROP ROLE regress_view_owner;
|
|
|
|
|
2016-10-21 15:54:29 +02:00
|
|
|
|
|
|
|
-- ===================================================================
|
|
|
|
-- Aggregate and grouping queries
|
|
|
|
-- ===================================================================
|
|
|
|
|
|
|
|
-- Simple aggregates
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select count(c6), sum(c1), avg(c1), min(c2), max(c1), stddev(c2), sum(c1) * (random() <= 1)::int as sum2 from ft1 where c2 < 5 group by c2 order by 1, 2;
|
|
|
|
select count(c6), sum(c1), avg(c1), min(c2), max(c1), stddev(c2), sum(c1) * (random() <= 1)::int as sum2 from ft1 where c2 < 5 group by c2 order by 1, 2;
|
|
|
|
|
2019-04-02 13:30:45 +02:00
|
|
|
explain (verbose, costs off)
|
|
|
|
select count(c6), sum(c1), avg(c1), min(c2), max(c1), stddev(c2), sum(c1) * (random() <= 1)::int as sum2 from ft1 where c2 < 5 group by c2 order by 1, 2 limit 1;
|
|
|
|
select count(c6), sum(c1), avg(c1), min(c2), max(c1), stddev(c2), sum(c1) * (random() <= 1)::int as sum2 from ft1 where c2 < 5 group by c2 order by 1, 2 limit 1;
|
|
|
|
|
2016-10-21 15:54:29 +02:00
|
|
|
-- Aggregate is not pushed down as aggregation contains random()
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select sum(c1 * (random() <= 1)::int) as sum, avg(c1) from ft1;
|
|
|
|
|
|
|
|
-- Aggregate over join query
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select count(*), sum(t1.c1), avg(t2.c1) from ft1 t1 inner join ft1 t2 on (t1.c2 = t2.c2) where t1.c2 = 6;
|
|
|
|
select count(*), sum(t1.c1), avg(t2.c1) from ft1 t1 inner join ft1 t2 on (t1.c2 = t2.c2) where t1.c2 = 6;
|
|
|
|
|
|
|
|
-- Not pushed down due to local conditions present in underneath input rel
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select sum(t1.c1), count(t2.c1) from ft1 t1 inner join ft2 t2 on (t1.c1 = t2.c1) where ((t1.c1 * t2.c1)/(t1.c1 * t2.c1)) * random() <= 1;
|
|
|
|
|
|
|
|
-- GROUP BY clause having expressions
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2/2, sum(c2) * (c2/2) from ft1 group by c2/2 order by c2/2;
|
|
|
|
select c2/2, sum(c2) * (c2/2) from ft1 group by c2/2 order by c2/2;
|
|
|
|
|
|
|
|
-- Aggregates in subquery are pushed down.
|
Remove pessimistic cost penalization from Incremental Sort
When incremental sorts were added in v13 a 1.5x pessimism factor was added
to the cost modal. Seemingly this was done because the cost modal only
has an estimate of the total number of input rows and the number of
presorted groups. It assumes that the input rows will be evenly
distributed throughout the presorted groups. The 1.5x pessimism factor
was added to slightly reduce the likelihood of incremental sorts being
used in the hope to avoid performance regressions where an incremental
sort plan was picked and turned out slower due to a large skew in the
number of rows in the presorted groups.
An additional quirk with the path generation code meant that we could
consider both a sort and an incremental sort on paths with presorted keys.
This meant that with the pessimism factor, it was possible that we opted
to perform a sort rather than an incremental sort when the given path had
presorted keys.
Here we remove the 1.5x pessimism factor to allow incremental sorts to
have a fairer chance at being chosen against a full sort.
Previously we would generally create a sort path on the cheapest input
path (if that wasn't sorted already) and incremental sort paths on any
path which had presorted keys. This meant that if the cheapest input path
wasn't completely sorted but happened to have presorted keys, we would
create a full sort path *and* an incremental sort path on that input path.
Here we change this logic so that if there are presorted keys, we only
create an incremental sort path, and create sort paths only when a full
sort is required.
Both the removal of the cost pessimism factor and the changes made to the
path generation make it more likely that incremental sorts will now be
chosen. That, of course, as with teaching the planner any new tricks,
means an increased likelihood that the planner will perform an incremental
sort when it's not the best method. Our standard escape hatch for these
cases is an enable_* GUC. enable_incremental_sort already exists for
this.
This came out of a report by Pavel Luzanov where he mentioned that the
master branch was choosing to perform a Seq Scan -> Sort -> Group
Aggregate for his query with an ORDER BY aggregate function. The v15 plan
for his query performed an Index Scan -> Group Aggregate, of course, the
aggregate performed the final sort internally in nodeAgg.c for the
aggregate's ORDER BY. The ideal plan would have been to use the index,
which provided partially sorted input then use an incremental sort to
provide the aggregate with the sorted input. This was not being chosen
due to the pessimism in the incremental sort cost modal, so here we remove
that and rationalize the path generation so that sort and incremental sort
plans don't have to needlessly compete. We assume that it's senseless
to ever use a full sort on a given input path where an incremental sort
can be performed.
Reported-by: Pavel Luzanov
Reviewed-by: Richard Guo
Discussion: https://postgr.es/m/9f61ddbf-2989-1536-b31e-6459370a6baa%40postgrespro.ru
2022-12-16 03:22:23 +01:00
|
|
|
set enable_incremental_sort = off;
|
2016-10-21 15:54:29 +02:00
|
|
|
explain (verbose, costs off)
|
|
|
|
select count(x.a), sum(x.a) from (select c2 a, sum(c1) b from ft1 group by c2, sqrt(c1) order by 1, 2) x;
|
|
|
|
select count(x.a), sum(x.a) from (select c2 a, sum(c1) b from ft1 group by c2, sqrt(c1) order by 1, 2) x;
|
Remove pessimistic cost penalization from Incremental Sort
When incremental sorts were added in v13 a 1.5x pessimism factor was added
to the cost modal. Seemingly this was done because the cost modal only
has an estimate of the total number of input rows and the number of
presorted groups. It assumes that the input rows will be evenly
distributed throughout the presorted groups. The 1.5x pessimism factor
was added to slightly reduce the likelihood of incremental sorts being
used in the hope to avoid performance regressions where an incremental
sort plan was picked and turned out slower due to a large skew in the
number of rows in the presorted groups.
An additional quirk with the path generation code meant that we could
consider both a sort and an incremental sort on paths with presorted keys.
This meant that with the pessimism factor, it was possible that we opted
to perform a sort rather than an incremental sort when the given path had
presorted keys.
Here we remove the 1.5x pessimism factor to allow incremental sorts to
have a fairer chance at being chosen against a full sort.
Previously we would generally create a sort path on the cheapest input
path (if that wasn't sorted already) and incremental sort paths on any
path which had presorted keys. This meant that if the cheapest input path
wasn't completely sorted but happened to have presorted keys, we would
create a full sort path *and* an incremental sort path on that input path.
Here we change this logic so that if there are presorted keys, we only
create an incremental sort path, and create sort paths only when a full
sort is required.
Both the removal of the cost pessimism factor and the changes made to the
path generation make it more likely that incremental sorts will now be
chosen. That, of course, as with teaching the planner any new tricks,
means an increased likelihood that the planner will perform an incremental
sort when it's not the best method. Our standard escape hatch for these
cases is an enable_* GUC. enable_incremental_sort already exists for
this.
This came out of a report by Pavel Luzanov where he mentioned that the
master branch was choosing to perform a Seq Scan -> Sort -> Group
Aggregate for his query with an ORDER BY aggregate function. The v15 plan
for his query performed an Index Scan -> Group Aggregate, of course, the
aggregate performed the final sort internally in nodeAgg.c for the
aggregate's ORDER BY. The ideal plan would have been to use the index,
which provided partially sorted input then use an incremental sort to
provide the aggregate with the sorted input. This was not being chosen
due to the pessimism in the incremental sort cost modal, so here we remove
that and rationalize the path generation so that sort and incremental sort
plans don't have to needlessly compete. We assume that it's senseless
to ever use a full sort on a given input path where an incremental sort
can be performed.
Reported-by: Pavel Luzanov
Reviewed-by: Richard Guo
Discussion: https://postgr.es/m/9f61ddbf-2989-1536-b31e-6459370a6baa%40postgrespro.ru
2022-12-16 03:22:23 +01:00
|
|
|
reset enable_incremental_sort;
|
2016-10-21 15:54:29 +02:00
|
|
|
|
|
|
|
-- Aggregate is still pushed down by taking unshippable expression out
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2 * (random() <= 1)::int as sum1, sum(c1) * c2 as sum2 from ft1 group by c2 order by 1, 2;
|
|
|
|
select c2 * (random() <= 1)::int as sum1, sum(c1) * c2 as sum2 from ft1 group by c2 order by 1, 2;
|
|
|
|
|
|
|
|
-- Aggregate with unshippable GROUP BY clause are not pushed
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2 * (random() <= 1)::int as c2 from ft2 group by c2 * (random() <= 1)::int order by 1;
|
|
|
|
|
|
|
|
-- GROUP BY clause in various forms, cardinal, alias and constant expression
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select count(c2) w, c2 x, 5 y, 7.0 z from ft1 group by 2, y, 9.0::int order by 2;
|
|
|
|
select count(c2) w, c2 x, 5 y, 7.0 z from ft1 group by 2, y, 9.0::int order by 2;
|
|
|
|
|
2018-01-12 22:52:49 +01:00
|
|
|
-- GROUP BY clause referring to same column multiple times
|
|
|
|
-- Also, ORDER BY contains an aggregate function
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2, c2 from ft1 where c2 > 6 group by 1, 2 order by sum(c1);
|
|
|
|
select c2, c2 from ft1 where c2 > 6 group by 1, 2 order by sum(c1);
|
|
|
|
|
2016-10-21 15:54:29 +02:00
|
|
|
-- Testing HAVING clause shippability
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2, sum(c1) from ft2 group by c2 having avg(c1) < 500 and sum(c1) < 49800 order by c2;
|
|
|
|
select c2, sum(c1) from ft2 group by c2 having avg(c1) < 500 and sum(c1) < 49800 order by c2;
|
|
|
|
|
|
|
|
-- Unshippable HAVING clause will be evaluated locally, and other qual in HAVING clause is pushed down
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select count(*) from (select c5, count(c1) from ft1 group by c5, sqrt(c2) having (avg(c1) / avg(c1)) * random() <= 1 and avg(c1) < 500) x;
|
|
|
|
select count(*) from (select c5, count(c1) from ft1 group by c5, sqrt(c2) having (avg(c1) / avg(c1)) * random() <= 1 and avg(c1) < 500) x;
|
|
|
|
|
|
|
|
-- Aggregate in HAVING clause is not pushable, and thus aggregation is not pushed down
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select sum(c1) from ft1 group by c2 having avg(c1 * (random() <= 1)::int) > 100 order by 1;
|
|
|
|
|
Avoid postgres_fdw crash for a targetlist entry that's just a Param.
foreign_grouping_ok() is willing to put fairly arbitrary expressions into
the targetlist of a remote SELECT that's doing grouping or aggregation on
the remote side, including expressions that have no foreign component to
them at all. This is possibly a bit dubious from an efficiency standpoint;
but it rises to the level of a crash-causing bug if the expression is just
a Param or non-foreign Var. In that case, the expression will necessarily
also appear in the fdw_exprs list of values we need to send to the remote
server, and then setrefs.c's set_foreignscan_references will mistakenly
replace the fdw_exprs entry with a Var referencing the targetlist result.
The root cause of this problem is bad design in commit e7cb7ee14: it put
logic into set_foreignscan_references that IMV is postgres_fdw-specific,
and yet this bug shows that it isn't postgres_fdw-specific enough. The
transformation being done on fdw_exprs assumes that fdw_exprs is to be
evaluated with the fdw_scan_tlist as input, which is not how postgres_fdw
uses it; yet it could be the right thing for some other FDW. (In the
bigger picture, setrefs.c has no business assuming this for the other
expression fields of a ForeignScan either.)
The right fix therefore would be to expand the FDW API so that the
FDW could inform setrefs.c how it intends to evaluate these various
expressions. We can't change that in the back branches though, and we
also can't just summarily change setrefs.c's behavior there, or we're
likely to break external FDWs.
As a stopgap, therefore, hack up postgres_fdw so that it won't attempt
to send targetlist entries that look exactly like the fdw_exprs entries
they'd produce. In most cases this actually produces a superior plan,
IMO, with less data needing to be transmitted and returned; so we probably
ought to think harder about whether we should ship tlist expressions at
all when they don't contain any foreign Vars or Aggs. But that's an
optimization not a bug fix so I left it for later. One case where this
produces an inferior plan is where the expression in question is actually
a GROUP BY expression: then the restriction prevents us from using remote
grouping. It might be possible to work around that (since that would
reduce to group-by-a-constant on the remote side); but it seems like a
pretty unlikely corner case, so I'm not sure it's worth expending effort
solely to improve that. In any case the right long-term answer is to fix
the API as sketched above, and then revert this hack.
Per bug #15781 from Sean Johnston. Back-patch to v10 where the problem
was introduced.
Discussion: https://postgr.es/m/15781-2601b1002bad087c@postgresql.org
2019-04-27 19:15:54 +02:00
|
|
|
-- Remote aggregate in combination with a local Param (for the output
|
|
|
|
-- of an initplan) can be trouble, per bug #15781
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select exists(select 1 from pg_enum), sum(c1) from ft1;
|
|
|
|
select exists(select 1 from pg_enum), sum(c1) from ft1;
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select exists(select 1 from pg_enum), sum(c1) from ft1 group by 1;
|
|
|
|
select exists(select 1 from pg_enum), sum(c1) from ft1 group by 1;
|
|
|
|
|
2016-10-21 15:54:29 +02:00
|
|
|
|
|
|
|
-- Testing ORDER BY, DISTINCT, FILTER, Ordered-sets and VARIADIC within aggregates
|
|
|
|
|
|
|
|
-- ORDER BY within aggregate, same column used to order
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select array_agg(c1 order by c1) from ft1 where c1 < 100 group by c2 order by 1;
|
|
|
|
select array_agg(c1 order by c1) from ft1 where c1 < 100 group by c2 order by 1;
|
|
|
|
|
|
|
|
-- ORDER BY within aggregate, different column used to order also using DESC
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select array_agg(c5 order by c1 desc) from ft2 where c2 = 6 and c1 < 50;
|
|
|
|
select array_agg(c5 order by c1 desc) from ft2 where c2 = 6 and c1 < 50;
|
|
|
|
|
|
|
|
-- DISTINCT within aggregate
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select array_agg(distinct (t1.c1)%5) from ft4 t1 full join ft5 t2 on (t1.c1 = t2.c1) where t1.c1 < 20 or (t1.c1 is null and t2.c1 < 5) group by (t2.c1)%3 order by 1;
|
|
|
|
select array_agg(distinct (t1.c1)%5) from ft4 t1 full join ft5 t2 on (t1.c1 = t2.c1) where t1.c1 < 20 or (t1.c1 is null and t2.c1 < 5) group by (t2.c1)%3 order by 1;
|
|
|
|
|
|
|
|
-- DISTINCT combined with ORDER BY within aggregate
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select array_agg(distinct (t1.c1)%5 order by (t1.c1)%5) from ft4 t1 full join ft5 t2 on (t1.c1 = t2.c1) where t1.c1 < 20 or (t1.c1 is null and t2.c1 < 5) group by (t2.c1)%3 order by 1;
|
|
|
|
select array_agg(distinct (t1.c1)%5 order by (t1.c1)%5) from ft4 t1 full join ft5 t2 on (t1.c1 = t2.c1) where t1.c1 < 20 or (t1.c1 is null and t2.c1 < 5) group by (t2.c1)%3 order by 1;
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select array_agg(distinct (t1.c1)%5 order by (t1.c1)%5 desc nulls last) from ft4 t1 full join ft5 t2 on (t1.c1 = t2.c1) where t1.c1 < 20 or (t1.c1 is null and t2.c1 < 5) group by (t2.c1)%3 order by 1;
|
|
|
|
select array_agg(distinct (t1.c1)%5 order by (t1.c1)%5 desc nulls last) from ft4 t1 full join ft5 t2 on (t1.c1 = t2.c1) where t1.c1 < 20 or (t1.c1 is null and t2.c1 < 5) group by (t2.c1)%3 order by 1;
|
|
|
|
|
|
|
|
-- FILTER within aggregate
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select sum(c1) filter (where c1 < 100 and c2 > 5) from ft1 group by c2 order by 1 nulls last;
|
|
|
|
select sum(c1) filter (where c1 < 100 and c2 > 5) from ft1 group by c2 order by 1 nulls last;
|
|
|
|
|
|
|
|
-- DISTINCT, ORDER BY and FILTER within aggregate
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select sum(c1%3), sum(distinct c1%3 order by c1%3) filter (where c1%3 < 2), c2 from ft1 where c2 = 6 group by c2;
|
|
|
|
select sum(c1%3), sum(distinct c1%3 order by c1%3) filter (where c1%3 < 2), c2 from ft1 where c2 = 6 group by c2;
|
|
|
|
|
|
|
|
-- Outer query is aggregation query
|
|
|
|
explain (verbose, costs off)
|
2017-01-25 14:31:31 +01:00
|
|
|
select distinct (select count(*) filter (where t2.c2 = 6 and t2.c1 < 10) from ft1 t1 where t1.c1 = 6) from ft2 t2 where t2.c2 % 6 = 0 order by 1;
|
|
|
|
select distinct (select count(*) filter (where t2.c2 = 6 and t2.c1 < 10) from ft1 t1 where t1.c1 = 6) from ft2 t2 where t2.c2 % 6 = 0 order by 1;
|
2016-10-21 15:54:29 +02:00
|
|
|
-- Inner query is aggregation query
|
|
|
|
explain (verbose, costs off)
|
2017-01-25 14:31:31 +01:00
|
|
|
select distinct (select count(t1.c1) filter (where t2.c2 = 6 and t2.c1 < 10) from ft1 t1 where t1.c1 = 6) from ft2 t2 where t2.c2 % 6 = 0 order by 1;
|
|
|
|
select distinct (select count(t1.c1) filter (where t2.c2 = 6 and t2.c1 < 10) from ft1 t1 where t1.c1 = 6) from ft2 t2 where t2.c2 % 6 = 0 order by 1;
|
2016-10-21 15:54:29 +02:00
|
|
|
|
|
|
|
-- Aggregate not pushed down as FILTER condition is not pushable
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select sum(c1) filter (where (c1 / c1) * random() <= 1) from ft1 group by c2 order by 1;
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select sum(c2) filter (where c2 in (select c2 from ft1 where c2 < 5)) from ft1;
|
|
|
|
|
|
|
|
-- Ordered-sets within aggregate
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2, rank('10'::varchar) within group (order by c6), percentile_cont(c2/10::numeric) within group (order by c1) from ft1 where c2 < 10 group by c2 having percentile_cont(c2/10::numeric) within group (order by c1) < 500 order by c2;
|
|
|
|
select c2, rank('10'::varchar) within group (order by c6), percentile_cont(c2/10::numeric) within group (order by c1) from ft1 where c2 < 10 group by c2 having percentile_cont(c2/10::numeric) within group (order by c1) < 500 order by c2;
|
|
|
|
|
|
|
|
-- Using multiple arguments within aggregates
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c1, rank(c1, c2) within group (order by c1, c2) from ft1 group by c1, c2 having c1 = 6 order by 1;
|
|
|
|
select c1, rank(c1, c2) within group (order by c1, c2) from ft1 group by c1, c2 having c1 = 6 order by 1;
|
|
|
|
|
|
|
|
-- User defined function for user defined aggregate, VARIADIC
|
|
|
|
create function least_accum(anyelement, variadic anyarray)
|
|
|
|
returns anyelement language sql as
|
|
|
|
'select least($1, min($2[i])) from generate_subscripts($2,1) g(i)';
|
|
|
|
create aggregate least_agg(variadic items anyarray) (
|
|
|
|
stype = anyelement, sfunc = least_accum
|
|
|
|
);
|
|
|
|
|
2016-10-21 17:27:32 +02:00
|
|
|
-- Disable hash aggregation for plan stability.
|
|
|
|
set enable_hashagg to false;
|
|
|
|
|
2016-10-21 15:54:29 +02:00
|
|
|
-- Not pushed down due to user defined aggregate
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2, least_agg(c1) from ft1 group by c2 order by c2;
|
|
|
|
|
|
|
|
-- Add function and aggregate into extension
|
|
|
|
alter extension postgres_fdw add function least_accum(anyelement, variadic anyarray);
|
|
|
|
alter extension postgres_fdw add aggregate least_agg(variadic items anyarray);
|
|
|
|
alter server loopback options (set extensions 'postgres_fdw');
|
|
|
|
|
|
|
|
-- Now aggregate will be pushed. Aggregate will display VARIADIC argument.
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2, least_agg(c1) from ft1 where c2 < 100 group by c2 order by c2;
|
|
|
|
select c2, least_agg(c1) from ft1 where c2 < 100 group by c2 order by c2;
|
|
|
|
|
|
|
|
-- Remove function and aggregate from extension
|
|
|
|
alter extension postgres_fdw drop function least_accum(anyelement, variadic anyarray);
|
|
|
|
alter extension postgres_fdw drop aggregate least_agg(variadic items anyarray);
|
|
|
|
alter server loopback options (set extensions 'postgres_fdw');
|
|
|
|
|
|
|
|
-- Not pushed down as we have dropped objects from extension.
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2, least_agg(c1) from ft1 group by c2 order by c2;
|
|
|
|
|
|
|
|
-- Cleanup
|
2016-10-21 17:27:32 +02:00
|
|
|
reset enable_hashagg;
|
2016-10-21 15:54:29 +02:00
|
|
|
drop aggregate least_agg(variadic items anyarray);
|
|
|
|
drop function least_accum(anyelement, variadic anyarray);
|
|
|
|
|
|
|
|
|
|
|
|
-- Testing USING OPERATOR() in ORDER BY within aggregate.
|
|
|
|
-- For this, we need user defined operators along with operator family and
|
|
|
|
-- operator class. Create those and then add them in extension. Note that
|
|
|
|
-- user defined objects are considered unshippable unless they are part of
|
|
|
|
-- the extension.
|
|
|
|
create operator public.<^ (
|
|
|
|
leftarg = int4,
|
|
|
|
rightarg = int4,
|
|
|
|
procedure = int4eq
|
|
|
|
);
|
|
|
|
|
|
|
|
create operator public.=^ (
|
|
|
|
leftarg = int4,
|
|
|
|
rightarg = int4,
|
|
|
|
procedure = int4lt
|
|
|
|
);
|
|
|
|
|
|
|
|
create operator public.>^ (
|
|
|
|
leftarg = int4,
|
|
|
|
rightarg = int4,
|
|
|
|
procedure = int4gt
|
|
|
|
);
|
|
|
|
|
|
|
|
create operator family my_op_family using btree;
|
|
|
|
|
|
|
|
create function my_op_cmp(a int, b int) returns int as
|
|
|
|
$$begin return btint4cmp(a, b); end $$ language plpgsql;
|
|
|
|
|
|
|
|
create operator class my_op_class for type int using btree family my_op_family as
|
|
|
|
operator 1 public.<^,
|
|
|
|
operator 3 public.=^,
|
|
|
|
operator 5 public.>^,
|
|
|
|
function 1 my_op_cmp(int, int);
|
|
|
|
|
|
|
|
-- This will not be pushed as user defined sort operator is not part of the
|
|
|
|
-- extension yet.
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select array_agg(c1 order by c1 using operator(public.<^)) from ft2 where c2 = 6 and c1 < 100 group by c2;
|
|
|
|
|
Fix postgres_fdw to check shippability of sort clauses properly.
postgres_fdw would push ORDER BY clauses to the remote side without
verifying that the sort operator is safe to ship. Moreover, it failed
to print a suitable USING clause if the sort operator isn't default
for the sort expression's type. The net result of this is that the
remote sort might not have anywhere near the semantics we expect,
which'd be disastrous for locally-performed merge joins in particular.
We addressed similar issues in the context of ORDER BY within an
aggregate function call in commit 7012b132d, but failed to notice
that query-level ORDER BY was broken. Thus, much of the necessary
logic already existed, but it requires refactoring to be usable
in both cases.
Back-patch to all supported branches. In HEAD only, remove the
core code's copy of find_em_expr_for_rel, which is no longer used
and really should never have been pushed into equivclass.c in the
first place.
Ronan Dunklau, per report from David Rowley;
reviews by David Rowley, Ranier Vilela, and myself
Discussion: https://postgr.es/m/CAApHDvr4OeC2DBVY--zVP83-K=bYrTD7F8SZDhN4g+pj2f2S-A@mail.gmail.com
2022-03-31 20:29:24 +02:00
|
|
|
-- This should not be pushed either.
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select * from ft2 order by c1 using operator(public.<^);
|
|
|
|
|
postgres_fdw: Improve cost and size estimation for aggregate pushdown.
In commit 7012b132d07c2b4ea15b0b3cb1ea9f3278801d98, which added aggregate
pushdown to postgres_fdw, we didn't account for the evaluation cost and the
selectivity of HAVING quals attached to ForeignPaths performing aggregate
pushdown, as core had never accounted for that for AggPaths and GroupPaths.
And we didn't set these values of the locally-checked quals (ie, fpinfo's
local_conds_cost and local_conds_sel), which were initialized to zeros, but
since estimate_path_cost_size factors in these to estimate the result size
and the evaluation cost of such a ForeignPath when the use_remote_estimate
option is enabled, this caused it to produce underestimated results in that
case.
By commit 7b6c07547190f056b0464098bb5a2247129d7aa2 core was changed so that
it accounts for the evaluation cost and the selectivity of HAVING quals in
aggregation paths, so change the postgres_fdw's aggregate pushdown code as
well as such. This not only fixes the underestimation issue mentioned
above, but improves the estimation using local statistics in that function
when that option is disabled.
This would be a bug fix rather than an improvement, but apply it to HEAD
only to avoid destabilizing existing plan choices.
Author: Etsuro Fujita
Discussion: https://postgr.es/m/5BFD3EAD.2060301%40lab.ntt.co.jp
2018-12-04 09:18:58 +01:00
|
|
|
-- Update local stats on ft2
|
|
|
|
ANALYZE ft2;
|
|
|
|
|
2016-10-21 15:54:29 +02:00
|
|
|
-- Add into extension
|
|
|
|
alter extension postgres_fdw add operator class my_op_class using btree;
|
|
|
|
alter extension postgres_fdw add function my_op_cmp(a int, b int);
|
|
|
|
alter extension postgres_fdw add operator family my_op_family using btree;
|
|
|
|
alter extension postgres_fdw add operator public.<^(int, int);
|
|
|
|
alter extension postgres_fdw add operator public.=^(int, int);
|
|
|
|
alter extension postgres_fdw add operator public.>^(int, int);
|
|
|
|
alter server loopback options (set extensions 'postgres_fdw');
|
|
|
|
|
|
|
|
-- Now this will be pushed as sort operator is part of the extension.
|
Improve performance of ORDER BY / DISTINCT aggregates
ORDER BY / DISTINCT aggreagtes have, since implemented in Postgres, been
executed by always performing a sort in nodeAgg.c to sort the tuples in
the current group into the correct order before calling the transition
function on the sorted tuples. This was not great as often there might be
an index that could have provided pre-sorted input and allowed the
transition functions to be called as the rows come in, rather than having
to store them in a tuplestore in order to sort them once all the tuples
for the group have arrived.
Here we change the planner so it requests a path with a sort order which
supports the most amount of ORDER BY / DISTINCT aggregate functions and
add new code to the executor to allow it to support the processing of
ORDER BY / DISTINCT aggregates where the tuples are already sorted in the
correct order.
Since there can be many ORDER BY / DISTINCT aggregates in any given query
level, it's very possible that we can't find an order that suits all of
these aggregates. The sort order that the planner chooses is simply the
one that suits the most aggregate functions. We take the most strictly
sorted variation of each order and see how many aggregate functions can
use that, then we try again with the order of the remaining aggregates to
see if another order would suit more aggregate functions. For example:
SELECT agg(a ORDER BY a),agg2(a ORDER BY a,b) ...
would request the sort order to be {a, b} because {a} is a subset of the
sort order of {a,b}, but;
SELECT agg(a ORDER BY a),agg2(a ORDER BY c) ...
would just pick a plan ordered by {a} (we give precedence to aggregates
which are earlier in the targetlist).
SELECT agg(a ORDER BY a),agg2(a ORDER BY b),agg3(a ORDER BY b) ...
would choose to order by {b} since two aggregates suit that vs just one
that requires input ordered by {a}.
Author: David Rowley
Reviewed-by: Ronan Dunklau, James Coleman, Ranier Vilela, Richard Guo, Tom Lane
Discussion: https://postgr.es/m/CAApHDvpHzfo92%3DR4W0%2BxVua3BUYCKMckWAmo-2t_KiXN-wYH%3Dw%40mail.gmail.com
2022-08-02 13:11:45 +02:00
|
|
|
alter server loopback options (add fdw_tuple_cost '0.5');
|
2016-10-21 15:54:29 +02:00
|
|
|
explain (verbose, costs off)
|
|
|
|
select array_agg(c1 order by c1 using operator(public.<^)) from ft2 where c2 = 6 and c1 < 100 group by c2;
|
|
|
|
select array_agg(c1 order by c1 using operator(public.<^)) from ft2 where c2 = 6 and c1 < 100 group by c2;
|
Improve performance of ORDER BY / DISTINCT aggregates
ORDER BY / DISTINCT aggreagtes have, since implemented in Postgres, been
executed by always performing a sort in nodeAgg.c to sort the tuples in
the current group into the correct order before calling the transition
function on the sorted tuples. This was not great as often there might be
an index that could have provided pre-sorted input and allowed the
transition functions to be called as the rows come in, rather than having
to store them in a tuplestore in order to sort them once all the tuples
for the group have arrived.
Here we change the planner so it requests a path with a sort order which
supports the most amount of ORDER BY / DISTINCT aggregate functions and
add new code to the executor to allow it to support the processing of
ORDER BY / DISTINCT aggregates where the tuples are already sorted in the
correct order.
Since there can be many ORDER BY / DISTINCT aggregates in any given query
level, it's very possible that we can't find an order that suits all of
these aggregates. The sort order that the planner chooses is simply the
one that suits the most aggregate functions. We take the most strictly
sorted variation of each order and see how many aggregate functions can
use that, then we try again with the order of the remaining aggregates to
see if another order would suit more aggregate functions. For example:
SELECT agg(a ORDER BY a),agg2(a ORDER BY a,b) ...
would request the sort order to be {a, b} because {a} is a subset of the
sort order of {a,b}, but;
SELECT agg(a ORDER BY a),agg2(a ORDER BY c) ...
would just pick a plan ordered by {a} (we give precedence to aggregates
which are earlier in the targetlist).
SELECT agg(a ORDER BY a),agg2(a ORDER BY b),agg3(a ORDER BY b) ...
would choose to order by {b} since two aggregates suit that vs just one
that requires input ordered by {a}.
Author: David Rowley
Reviewed-by: Ronan Dunklau, James Coleman, Ranier Vilela, Richard Guo, Tom Lane
Discussion: https://postgr.es/m/CAApHDvpHzfo92%3DR4W0%2BxVua3BUYCKMckWAmo-2t_KiXN-wYH%3Dw%40mail.gmail.com
2022-08-02 13:11:45 +02:00
|
|
|
alter server loopback options (drop fdw_tuple_cost);
|
2016-10-21 15:54:29 +02:00
|
|
|
|
Fix postgres_fdw to check shippability of sort clauses properly.
postgres_fdw would push ORDER BY clauses to the remote side without
verifying that the sort operator is safe to ship. Moreover, it failed
to print a suitable USING clause if the sort operator isn't default
for the sort expression's type. The net result of this is that the
remote sort might not have anywhere near the semantics we expect,
which'd be disastrous for locally-performed merge joins in particular.
We addressed similar issues in the context of ORDER BY within an
aggregate function call in commit 7012b132d, but failed to notice
that query-level ORDER BY was broken. Thus, much of the necessary
logic already existed, but it requires refactoring to be usable
in both cases.
Back-patch to all supported branches. In HEAD only, remove the
core code's copy of find_em_expr_for_rel, which is no longer used
and really should never have been pushed into equivclass.c in the
first place.
Ronan Dunklau, per report from David Rowley;
reviews by David Rowley, Ranier Vilela, and myself
Discussion: https://postgr.es/m/CAApHDvr4OeC2DBVY--zVP83-K=bYrTD7F8SZDhN4g+pj2f2S-A@mail.gmail.com
2022-03-31 20:29:24 +02:00
|
|
|
-- This should be pushed too.
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select * from ft2 order by c1 using operator(public.<^);
|
|
|
|
|
2016-10-21 15:54:29 +02:00
|
|
|
-- Remove from extension
|
|
|
|
alter extension postgres_fdw drop operator class my_op_class using btree;
|
|
|
|
alter extension postgres_fdw drop function my_op_cmp(a int, b int);
|
|
|
|
alter extension postgres_fdw drop operator family my_op_family using btree;
|
|
|
|
alter extension postgres_fdw drop operator public.<^(int, int);
|
|
|
|
alter extension postgres_fdw drop operator public.=^(int, int);
|
|
|
|
alter extension postgres_fdw drop operator public.>^(int, int);
|
|
|
|
alter server loopback options (set extensions 'postgres_fdw');
|
|
|
|
|
|
|
|
-- This will not be pushed as sort operator is now removed from the extension.
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select array_agg(c1 order by c1 using operator(public.<^)) from ft2 where c2 = 6 and c1 < 100 group by c2;
|
|
|
|
|
|
|
|
-- Cleanup
|
|
|
|
drop operator class my_op_class using btree;
|
|
|
|
drop function my_op_cmp(a int, b int);
|
|
|
|
drop operator family my_op_family using btree;
|
|
|
|
drop operator public.>^(int, int);
|
|
|
|
drop operator public.=^(int, int);
|
|
|
|
drop operator public.<^(int, int);
|
|
|
|
|
|
|
|
-- Input relation to aggregate push down hook is not safe to pushdown and thus
|
|
|
|
-- the aggregate cannot be pushed down to foreign server.
|
|
|
|
explain (verbose, costs off)
|
2017-12-01 19:47:00 +01:00
|
|
|
select count(t1.c3) from ft2 t1 left join ft2 t2 on (t1.c1 = random() * t2.c2);
|
2016-10-21 15:54:29 +02:00
|
|
|
|
|
|
|
-- Subquery in FROM clause having aggregate
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select count(*), x.b from ft1, (select c2 a, sum(c1) b from ft1 group by c2) x where ft1.c2 = x.a group by x.b order by 1, 2;
|
|
|
|
select count(*), x.b from ft1, (select c2 a, sum(c1) b from ft1 group by c2) x where ft1.c2 = x.a group by x.b order by 1, 2;
|
|
|
|
|
|
|
|
-- FULL join with IS NULL check in HAVING
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select avg(t1.c1), sum(t2.c1) from ft4 t1 full join ft5 t2 on (t1.c1 = t2.c1) group by t2.c1 having (avg(t1.c1) is null and sum(t2.c1) < 10) or sum(t2.c1) is null order by 1 nulls last, 2;
|
|
|
|
select avg(t1.c1), sum(t2.c1) from ft4 t1 full join ft5 t2 on (t1.c1 = t2.c1) group by t2.c1 having (avg(t1.c1) is null and sum(t2.c1) < 10) or sum(t2.c1) is null order by 1 nulls last, 2;
|
|
|
|
|
2017-03-16 18:34:59 +01:00
|
|
|
-- Aggregate over FULL join needing to deparse the joining relations as
|
|
|
|
-- subqueries.
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select count(*), sum(t1.c1), avg(t2.c1) from (select c1 from ft4 where c1 between 50 and 60) t1 full join (select c1 from ft5 where c1 between 50 and 60) t2 on (t1.c1 = t2.c1);
|
|
|
|
select count(*), sum(t1.c1), avg(t2.c1) from (select c1 from ft4 where c1 between 50 and 60) t1 full join (select c1 from ft5 where c1 between 50 and 60) t2 on (t1.c1 = t2.c1);
|
|
|
|
|
2016-10-21 15:54:29 +02:00
|
|
|
-- ORDER BY expression is part of the target list but not pushed down to
|
|
|
|
-- foreign server.
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select sum(c2) * (random() <= 1)::int as sum from ft1 order by 1;
|
|
|
|
select sum(c2) * (random() <= 1)::int as sum from ft1 order by 1;
|
|
|
|
|
|
|
|
-- LATERAL join, with parameterization
|
|
|
|
set enable_hashagg to false;
|
|
|
|
explain (verbose, costs off)
|
2017-01-25 14:31:31 +01:00
|
|
|
select c2, sum from "S 1"."T 1" t1, lateral (select sum(t2.c1 + t1."C 1") sum from ft2 t2 group by t2.c1) qry where t1.c2 * 2 = qry.sum and t1.c2 < 3 and t1."C 1" < 100 order by 1;
|
|
|
|
select c2, sum from "S 1"."T 1" t1, lateral (select sum(t2.c1 + t1."C 1") sum from ft2 t2 group by t2.c1) qry where t1.c2 * 2 = qry.sum and t1.c2 < 3 and t1."C 1" < 100 order by 1;
|
2016-10-21 15:54:29 +02:00
|
|
|
reset enable_hashagg;
|
|
|
|
|
Split create_foreignscan_path() into three functions.
Up to now postgres_fdw has been using create_foreignscan_path() to
generate not only base-relation paths, but also paths for foreign joins
and foreign upperrels. This is wrong, because create_foreignscan_path()
calls get_baserel_parampathinfo() which will only do the right thing for
baserels. It accidentally fails to fail for unparameterized paths, which
are the only ones postgres_fdw (thought it) was handling, but we really
need different APIs for the baserel and join cases.
In HEAD, the best thing to do seems to be to split up the baserel,
joinrel, and upperrel cases into three functions so that they can
have different APIs. I haven't actually given create_foreign_join_path
a different API in this commit: we should spend a bit of time thinking
about just what we want to do there, since perhaps FDWs would want to
do something different from the build-up-a-join-pairwise approach that
get_joinrel_parampathinfo expects. In the meantime, since postgres_fdw
isn't prepared to generate parameterized joins anyway, just give it a
defense against trying to plan joins with lateral refs.
In addition (and this is what triggered this whole mess) fix bug #15613
from Srinivasan S A, by teaching file_fdw and postgres_fdw that plain
baserel foreign paths still have outer refs if the relation has
lateral_relids. Add some assertions in relnode.c to catch future
occurrences of the same error --- in particular, to catch other FDWs
doing that, but also as backstop against core-code mistakes like the
one fixed by commit bdd9a99aa.
Bug #15613 also needs to be fixed in the back branches, but the
appropriate fix will look quite a bit different there, since we don't
want to assume that existing FDWs get the word right away.
Discussion: https://postgr.es/m/15613-092be1be9576c728@postgresql.org
2019-02-07 18:59:47 +01:00
|
|
|
-- bug #15613: bad plan for foreign table scan with lateral reference
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT ref_0.c2, subq_1.*
|
|
|
|
FROM
|
|
|
|
"S 1"."T 1" AS ref_0,
|
|
|
|
LATERAL (
|
|
|
|
SELECT ref_0."C 1" c1, subq_0.*
|
|
|
|
FROM (SELECT ref_0.c2, ref_1.c3
|
|
|
|
FROM ft1 AS ref_1) AS subq_0
|
|
|
|
RIGHT JOIN ft2 AS ref_3 ON (subq_0.c3 = ref_3.c3)
|
|
|
|
) AS subq_1
|
|
|
|
WHERE ref_0."C 1" < 10 AND subq_1.c3 = '00001'
|
|
|
|
ORDER BY ref_0."C 1";
|
|
|
|
|
|
|
|
SELECT ref_0.c2, subq_1.*
|
|
|
|
FROM
|
|
|
|
"S 1"."T 1" AS ref_0,
|
|
|
|
LATERAL (
|
|
|
|
SELECT ref_0."C 1" c1, subq_0.*
|
|
|
|
FROM (SELECT ref_0.c2, ref_1.c3
|
|
|
|
FROM ft1 AS ref_1) AS subq_0
|
|
|
|
RIGHT JOIN ft2 AS ref_3 ON (subq_0.c3 = ref_3.c3)
|
|
|
|
) AS subq_1
|
|
|
|
WHERE ref_0."C 1" < 10 AND subq_1.c3 = '00001'
|
|
|
|
ORDER BY ref_0."C 1";
|
|
|
|
|
2016-10-21 15:54:29 +02:00
|
|
|
-- Check with placeHolderVars
|
|
|
|
explain (verbose, costs off)
|
2016-10-25 04:36:24 +02:00
|
|
|
select sum(q.a), count(q.b) from ft4 left join (select 13, avg(ft1.c1), sum(ft2.c1) from ft1 right join ft2 on (ft1.c1 = ft2.c1)) q(a, b, c) on (ft4.c1 <= q.b);
|
|
|
|
select sum(q.a), count(q.b) from ft4 left join (select 13, avg(ft1.c1), sum(ft2.c1) from ft1 right join ft2 on (ft1.c1 = ft2.c1)) q(a, b, c) on (ft4.c1 <= q.b);
|
2016-10-21 15:54:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
-- Not supported cases
|
|
|
|
-- Grouping sets
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2, sum(c1) from ft1 where c2 < 3 group by rollup(c2) order by 1 nulls last;
|
|
|
|
select c2, sum(c1) from ft1 where c2 < 3 group by rollup(c2) order by 1 nulls last;
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2, sum(c1) from ft1 where c2 < 3 group by cube(c2) order by 1 nulls last;
|
|
|
|
select c2, sum(c1) from ft1 where c2 < 3 group by cube(c2) order by 1 nulls last;
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2, c6, sum(c1) from ft1 where c2 < 3 group by grouping sets(c2, c6) order by 1 nulls last, 2 nulls last;
|
|
|
|
select c2, c6, sum(c1) from ft1 where c2 < 3 group by grouping sets(c2, c6) order by 1 nulls last, 2 nulls last;
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2, sum(c1), grouping(c2) from ft1 where c2 < 3 group by c2 order by 1 nulls last;
|
|
|
|
select c2, sum(c1), grouping(c2) from ft1 where c2 < 3 group by c2 order by 1 nulls last;
|
|
|
|
|
|
|
|
-- DISTINCT itself is not pushed down, whereas underneath aggregate is pushed
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select distinct sum(c1)/1000 s from ft2 where c2 < 6 group by c2 order by 1;
|
|
|
|
select distinct sum(c1)/1000 s from ft2 where c2 < 6 group by c2 order by 1;
|
|
|
|
|
|
|
|
-- WindowAgg
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2, sum(c2), count(c2) over (partition by c2%2) from ft2 where c2 < 10 group by c2 order by 1;
|
|
|
|
select c2, sum(c2), count(c2) over (partition by c2%2) from ft2 where c2 < 10 group by c2 order by 1;
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2, array_agg(c2) over (partition by c2%2 order by c2 desc) from ft1 where c2 < 10 group by c2 order by 1;
|
|
|
|
select c2, array_agg(c2) over (partition by c2%2 order by c2 desc) from ft1 where c2 < 10 group by c2 order by 1;
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select c2, array_agg(c2) over (partition by c2%2 order by c2 range between current row and unbounded following) from ft1 where c2 < 10 group by c2 order by 1;
|
|
|
|
select c2, array_agg(c2) over (partition by c2%2 order by c2 range between current row and unbounded following) from ft1 where c2 < 10 group by c2 order by 1;
|
|
|
|
|
|
|
|
|
2013-02-21 11:26:23 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- parameterized queries
|
|
|
|
-- ===================================================================
|
|
|
|
-- simple join
|
|
|
|
PREPARE st1(int, int) AS SELECT t1.c3, t2.c3 FROM ft1 t1, ft2 t2 WHERE t1.c1 = $1 AND t2.c1 = $2;
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st1(1, 2);
|
2013-02-21 11:26:23 +01:00
|
|
|
EXECUTE st1(1, 1);
|
|
|
|
EXECUTE st1(101, 101);
|
|
|
|
-- subquery using stable function (can't be sent to remote)
|
2013-03-14 00:46:31 +01:00
|
|
|
PREPARE st2(int) AS SELECT * FROM ft1 t1 WHERE t1.c1 < $2 AND t1.c3 IN (SELECT c3 FROM ft2 t2 WHERE c1 > $1 AND date(c4) = '1970-01-17'::date) ORDER BY c1;
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st2(10, 20);
|
2013-02-21 11:26:23 +01:00
|
|
|
EXECUTE st2(10, 20);
|
2013-03-14 00:46:31 +01:00
|
|
|
EXECUTE st2(101, 121);
|
2013-02-21 11:26:23 +01:00
|
|
|
-- subquery using immutable function (can be sent to remote)
|
2013-03-14 00:46:31 +01:00
|
|
|
PREPARE st3(int) AS SELECT * FROM ft1 t1 WHERE t1.c1 < $2 AND t1.c3 IN (SELECT c3 FROM ft2 t2 WHERE c1 > $1 AND date(c5) = '1970-01-17'::date) ORDER BY c1;
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st3(10, 20);
|
2013-02-21 11:26:23 +01:00
|
|
|
EXECUTE st3(10, 20);
|
|
|
|
EXECUTE st3(20, 30);
|
|
|
|
-- custom plan should be chosen initially
|
|
|
|
PREPARE st4(int) AS SELECT * FROM ft1 t1 WHERE t1.c1 = $1;
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st4(1);
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st4(1);
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st4(1);
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st4(1);
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st4(1);
|
2013-02-21 11:26:23 +01:00
|
|
|
-- once we try it enough times, should switch to generic plan
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st4(1);
|
2013-02-21 11:26:23 +01:00
|
|
|
-- value of $1 should not be sent to remote
|
|
|
|
PREPARE st5(user_enum,int) AS SELECT * FROM ft1 t1 WHERE c8 = $1 and c1 = $2;
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st5('foo', 1);
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st5('foo', 1);
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st5('foo', 1);
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st5('foo', 1);
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st5('foo', 1);
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st5('foo', 1);
|
2013-02-21 11:26:23 +01:00
|
|
|
EXECUTE st5('foo', 1);
|
|
|
|
|
Invalidate cached plans on FDW option changes.
This fixes problems where a plan must change but fails to do so,
as seen in a bug report from Rajkumar Raghuwanshi.
For ALTER FOREIGN TABLE OPTIONS, do this through the standard method of
forcing a relcache flush on the table. For ALTER FOREIGN DATA WRAPPER
and ALTER SERVER, just flush the whole plan cache on any change in
pg_foreign_data_wrapper or pg_foreign_server. That matches the way
we handle some other low-probability cases such as opclass changes, and
it's unclear that the case arises often enough to be worth working harder.
Besides, that gives a patch that is simple enough to back-patch with
confidence.
Back-patch to 9.3. In principle we could apply the code change to 9.2 as
well, but (a) we lack postgres_fdw to test it with, (b) it's doubtful that
anyone is doing anything exciting enough with FDWs that far back to need
this desperately, and (c) the patch doesn't apply cleanly.
Patch originally by Amit Langote, reviewed by Etsuro Fujita and Ashutosh
Bapat, who each contributed substantial changes as well.
Discussion: https://postgr.es/m/CAKcux6m5cA6rRPTKkqVdJ-R=KKDfe35Q_ZuUqxDSV_4hwga=og@mail.gmail.com
2017-01-06 20:12:52 +01:00
|
|
|
-- altering FDW options requires replanning
|
|
|
|
PREPARE st6 AS SELECT * FROM ft1 t1 WHERE t1.c1 = t1.c2;
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st6;
|
|
|
|
PREPARE st7 AS INSERT INTO ft1 (c1,c2,c3) VALUES (1001,101,'foo');
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st7;
|
|
|
|
ALTER TABLE "S 1"."T 1" RENAME TO "T 0";
|
|
|
|
ALTER FOREIGN TABLE ft1 OPTIONS (SET table_name 'T 0');
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st6;
|
|
|
|
EXECUTE st6;
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st7;
|
|
|
|
ALTER TABLE "S 1"."T 0" RENAME TO "T 1";
|
|
|
|
ALTER FOREIGN TABLE ft1 OPTIONS (SET table_name 'T 1');
|
|
|
|
|
|
|
|
PREPARE st8 AS SELECT count(c3) FROM ft1 t1 WHERE t1.c1 === t1.c2;
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st8;
|
|
|
|
ALTER SERVER loopback OPTIONS (DROP extensions);
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) EXECUTE st8;
|
|
|
|
EXECUTE st8;
|
|
|
|
ALTER SERVER loopback OPTIONS (ADD extensions 'postgres_fdw');
|
|
|
|
|
2013-02-21 11:26:23 +01:00
|
|
|
-- cleanup
|
|
|
|
DEALLOCATE st1;
|
|
|
|
DEALLOCATE st2;
|
|
|
|
DEALLOCATE st3;
|
|
|
|
DEALLOCATE st4;
|
|
|
|
DEALLOCATE st5;
|
Invalidate cached plans on FDW option changes.
This fixes problems where a plan must change but fails to do so,
as seen in a bug report from Rajkumar Raghuwanshi.
For ALTER FOREIGN TABLE OPTIONS, do this through the standard method of
forcing a relcache flush on the table. For ALTER FOREIGN DATA WRAPPER
and ALTER SERVER, just flush the whole plan cache on any change in
pg_foreign_data_wrapper or pg_foreign_server. That matches the way
we handle some other low-probability cases such as opclass changes, and
it's unclear that the case arises often enough to be worth working harder.
Besides, that gives a patch that is simple enough to back-patch with
confidence.
Back-patch to 9.3. In principle we could apply the code change to 9.2 as
well, but (a) we lack postgres_fdw to test it with, (b) it's doubtful that
anyone is doing anything exciting enough with FDWs that far back to need
this desperately, and (c) the patch doesn't apply cleanly.
Patch originally by Amit Langote, reviewed by Etsuro Fujita and Ashutosh
Bapat, who each contributed substantial changes as well.
Discussion: https://postgr.es/m/CAKcux6m5cA6rRPTKkqVdJ-R=KKDfe35Q_ZuUqxDSV_4hwga=og@mail.gmail.com
2017-01-06 20:12:52 +01:00
|
|
|
DEALLOCATE st6;
|
|
|
|
DEALLOCATE st7;
|
|
|
|
DEALLOCATE st8;
|
2013-02-21 11:26:23 +01:00
|
|
|
|
2016-08-26 15:33:57 +02:00
|
|
|
-- System columns, except ctid and oid, should not be sent to remote
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2014-11-22 22:01:05 +01:00
|
|
|
SELECT * FROM ft1 t1 WHERE t1.tableoid = 'pg_class'::regclass LIMIT 1;
|
|
|
|
SELECT * FROM ft1 t1 WHERE t1.tableoid = 'ft1'::regclass LIMIT 1;
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2014-11-22 22:01:05 +01:00
|
|
|
SELECT tableoid::regclass, * FROM ft1 t1 LIMIT 1;
|
|
|
|
SELECT tableoid::regclass, * FROM ft1 t1 LIMIT 1;
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2014-11-22 22:01:05 +01:00
|
|
|
SELECT * FROM ft1 t1 WHERE t1.ctid = '(0,2)';
|
|
|
|
SELECT * FROM ft1 t1 WHERE t1.ctid = '(0,2)';
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
2014-11-22 22:01:05 +01:00
|
|
|
SELECT ctid, * FROM ft1 t1 LIMIT 1;
|
|
|
|
SELECT ctid, * FROM ft1 t1 LIMIT 1;
|
|
|
|
|
2013-02-21 11:26:23 +01:00
|
|
|
-- ===================================================================
|
2017-04-05 06:38:25 +02:00
|
|
|
-- used in PL/pgSQL function
|
2013-02-21 11:26:23 +01:00
|
|
|
-- ===================================================================
|
|
|
|
CREATE OR REPLACE FUNCTION f_test(p_c1 int) RETURNS int AS $$
|
|
|
|
DECLARE
|
|
|
|
v_c1 int;
|
|
|
|
BEGIN
|
|
|
|
SELECT c1 INTO v_c1 FROM ft1 WHERE c1 = p_c1 LIMIT 1;
|
|
|
|
PERFORM c1 FROM ft1 WHERE c1 = p_c1 AND p_c1 = v_c1 LIMIT 1;
|
|
|
|
RETURN v_c1;
|
|
|
|
END;
|
|
|
|
$$ LANGUAGE plpgsql;
|
|
|
|
SELECT f_test(100);
|
|
|
|
DROP FUNCTION f_test(int);
|
|
|
|
|
Add support for partitioned tables and indexes in REINDEX
Until now, REINDEX was not able to work with partitioned tables and
indexes, forcing users to reindex partitions one by one. This extends
REINDEX INDEX and REINDEX TABLE so as they can accept a partitioned
index and table in input, respectively, to reindex all the partitions
assigned to them with physical storage (foreign tables, partitioned
tables and indexes are then discarded).
This shares some logic with schema and database REINDEX as each
partition gets processed in its own transaction after building a list of
relations to work on. This choice has the advantage to minimize the
number of invalid indexes to one partition with REINDEX CONCURRENTLY in
the event a cancellation or failure in-flight, as the only indexes
handled at once in a single REINDEX CONCURRENTLY loop are the ones from
the partition being working on.
Isolation tests are added to emulate some cases I bumped into while
developing this feature, particularly with the concurrent drop of a
leaf partition reindexed. However, this is rather limited as LOCK would
cause REINDEX to block in the first transaction building the list of
partitions.
Per its multi-transaction nature, this new flavor cannot run in a
transaction block, similarly to REINDEX SCHEMA, SYSTEM and DATABASE.
Author: Justin Pryzby, Michael Paquier
Reviewed-by: Anastasia Lubennikova
Discussion: https://postgr.es/m/db12e897-73ff-467e-94cb-4af03705435f.adger.lj@alibaba-inc.com
2020-09-08 03:09:22 +02:00
|
|
|
-- ===================================================================
|
|
|
|
-- REINDEX
|
|
|
|
-- ===================================================================
|
|
|
|
-- remote table is not created here
|
|
|
|
CREATE FOREIGN TABLE reindex_foreign (c1 int, c2 int)
|
|
|
|
SERVER loopback2 OPTIONS (table_name 'reindex_local');
|
|
|
|
REINDEX TABLE reindex_foreign; -- error
|
|
|
|
REINDEX TABLE CONCURRENTLY reindex_foreign; -- error
|
|
|
|
DROP FOREIGN TABLE reindex_foreign;
|
|
|
|
-- partitions and foreign tables
|
|
|
|
CREATE TABLE reind_fdw_parent (c1 int) PARTITION BY RANGE (c1);
|
|
|
|
CREATE TABLE reind_fdw_0_10 PARTITION OF reind_fdw_parent
|
|
|
|
FOR VALUES FROM (0) TO (10);
|
|
|
|
CREATE FOREIGN TABLE reind_fdw_10_20 PARTITION OF reind_fdw_parent
|
|
|
|
FOR VALUES FROM (10) TO (20)
|
|
|
|
SERVER loopback OPTIONS (table_name 'reind_local_10_20');
|
|
|
|
REINDEX TABLE reind_fdw_parent; -- ok
|
|
|
|
REINDEX TABLE CONCURRENTLY reind_fdw_parent; -- ok
|
|
|
|
DROP TABLE reind_fdw_parent;
|
|
|
|
|
2013-02-21 11:26:23 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- conversion error
|
|
|
|
-- ===================================================================
|
|
|
|
ALTER FOREIGN TABLE ft1 ALTER COLUMN c8 TYPE int;
|
2021-07-06 18:36:12 +02:00
|
|
|
SELECT * FROM ft1 ftx(x1,x2,x3,x4,x5,x6,x7,x8) WHERE x1 = 1; -- ERROR
|
|
|
|
SELECT ftx.x1, ft2.c2, ftx.x8 FROM ft1 ftx(x1,x2,x3,x4,x5,x6,x7,x8), ft2
|
|
|
|
WHERE ftx.x1 = ft2.c1 AND ftx.x1 = 1; -- ERROR
|
|
|
|
SELECT ftx.x1, ft2.c2, ftx FROM ft1 ftx(x1,x2,x3,x4,x5,x6,x7,x8), ft2
|
|
|
|
WHERE ftx.x1 = ft2.c1 AND ftx.x1 = 1; -- ERROR
|
2016-10-21 15:54:29 +02:00
|
|
|
SELECT sum(c2), array_agg(c8) FROM ft1 GROUP BY c8; -- ERROR
|
2021-10-06 21:50:24 +02:00
|
|
|
ANALYZE ft1; -- ERROR
|
2013-02-21 11:26:23 +01:00
|
|
|
ALTER FOREIGN TABLE ft1 ALTER COLUMN c8 TYPE user_enum;
|
|
|
|
|
postgres_fdw: suppress casts on constants in limited cases.
When deparsing an expression of the form "remote_var OP constant",
we'd normally apply a cast to the constant to make sure that the
remote parser thinks it's of the same type we do. However, doing
so is often not necessary, and it causes problems if the user has
intentionally declared the local column as being of a different
type than the remote column. A plausible use-case for that is
using text to represent a type that's an enum on the remote side.
A comparison on such a column will get shipped as "var = 'foo'::text",
which blows up on the remote side because there's no enum = text
operator. But if we simply leave off the explicit cast, the
comparison will do exactly what the user wants.
It's possible to do this without major risk of semantic problems, by
relying on the longstanding parser heuristic that "if one operand of
an operator is of type unknown, while the other one has a known type,
assume that the unknown operand is also of that type". Hence, this
patch leaves off the cast only if (a) the operator inputs have the same
type locally; (b) the constant will print as a string literal or NULL,
both of which are initially taken as type unknown; and (c) the non-Const
input is a plain foreign Var. Rule (c) guarantees that the remote
parser will know the type of the non-Const input; moreover, it means
that if this cast-omission does cause any semantic surprises, that can
only happen in cases where the local column has a different type than
the remote column. That wasn't guaranteed to work anyway, and this
patch should represent a net usability gain for such cases.
One point that I (tgl) remain slightly uncomfortable with is that we
will ignore an implicit RelabelType when deciding if the non-Const input
is a plain Var. That makes it a little squishy to argue that the remote
should resolve the Const as being of the same type as its Var, because
then our Const is not the same type as our Var. However, if we don't do
that, then this hack won't work as desired if the user chooses to use
varchar rather than text to represent some remote column. That seems
useful, so do it like this for now. We might have to give up the
RelabelType-ignoring bit if any problems surface.
Dian Fay, with review and kibitzing by me
Discussion: https://postgr.es/m/C9LU294V7K4F.34LRRDU449O45@lamia
2021-11-12 17:50:40 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- local type can be different from remote type in some cases,
|
|
|
|
-- in particular if similarly-named operators do equivalent things
|
|
|
|
-- ===================================================================
|
|
|
|
ALTER FOREIGN TABLE ft1 ALTER COLUMN c8 TYPE text;
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM ft1 WHERE c8 = 'foo' LIMIT 1;
|
|
|
|
SELECT * FROM ft1 WHERE c8 = 'foo' LIMIT 1;
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM ft1 WHERE 'foo' = c8 LIMIT 1;
|
|
|
|
SELECT * FROM ft1 WHERE 'foo' = c8 LIMIT 1;
|
|
|
|
-- we declared c8 to be text locally, but it's still the same type on
|
|
|
|
-- the remote which will balk if we try to do anything incompatible
|
|
|
|
-- with that remote type
|
|
|
|
SELECT * FROM ft1 WHERE c8 LIKE 'foo' LIMIT 1; -- ERROR
|
|
|
|
SELECT * FROM ft1 WHERE c8::text LIKE 'foo' LIMIT 1; -- ERROR; cast not pushed down
|
|
|
|
ALTER FOREIGN TABLE ft1 ALTER COLUMN c8 TYPE user_enum;
|
|
|
|
|
2013-02-21 11:26:23 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- subtransaction
|
|
|
|
-- + local/remote error doesn't break cursor
|
|
|
|
-- ===================================================================
|
|
|
|
BEGIN;
|
|
|
|
DECLARE c CURSOR FOR SELECT * FROM ft1 ORDER BY c1;
|
|
|
|
FETCH c;
|
|
|
|
SAVEPOINT s;
|
|
|
|
ERROR OUT; -- ERROR
|
|
|
|
ROLLBACK TO s;
|
|
|
|
FETCH c;
|
|
|
|
SAVEPOINT s;
|
|
|
|
SELECT * FROM ft1 WHERE 1 / (c1 - 1) > 0; -- ERROR
|
|
|
|
ROLLBACK TO s;
|
|
|
|
FETCH c;
|
|
|
|
SELECT * FROM ft1 ORDER BY c1 LIMIT 1;
|
|
|
|
COMMIT;
|
2013-03-10 19:14:53 +01:00
|
|
|
|
2013-03-14 00:46:31 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- test handling of collations
|
|
|
|
-- ===================================================================
|
Improve handling of collations in contrib/postgres_fdw.
If we have a local Var of say varchar type with default collation, and
we apply a RelabelType to convert that to text with default collation, we
don't want to consider that as creating an FDW_COLLATE_UNSAFE situation.
It should be okay to compare that to a remote Var, so long as the remote
Var determines the comparison collation. (When we actually ship such an
expression to the remote side, the local Var would become a Param with
default collation, meaning the remote Var would in fact control the
comparison collation, because non-default implicit collation overrides
default implicit collation in parse_collate.c.) To fix, be more precise
about what FDW_COLLATE_NONE means: it applies either to a noncollatable
data type or to a collatable type with default collation, if that collation
can't be traced to a remote Var. (When it can, FDW_COLLATE_SAFE is
appropriate.) We were essentially using that interpretation already at
the Var/Const/Param level, but we weren't bubbling it up properly.
An alternative fix would be to introduce a separate FDW_COLLATE_DEFAULT
value to describe the second situation, but that would add more code
without changing the actual behavior, so it didn't seem worthwhile.
Also, since we're clarifying the rule to be that we care about whether
operator/function input collations match, there seems no need to fail
immediately upon seeing a Const/Param/non-foreign-Var with nondefault
collation. We only have to reject if it appears in a collation-sensitive
context (for example, "var IS NOT NULL" is perfectly safe from a collation
standpoint, whatever collation the var has). So just set the state to
UNSAFE rather than failing immediately.
Per report from Jeevan Chalke. This essentially corrects some sloppy
thinking in commit ed3ddf918b59545583a4b374566bc1148e75f593, so back-patch
to 9.3 where that logic appeared.
2015-09-24 18:47:29 +02:00
|
|
|
create table loct3 (f1 text collate "C" unique, f2 text, f3 varchar(10) unique);
|
|
|
|
create foreign table ft3 (f1 text collate "C", f2 text, f3 varchar(10))
|
|
|
|
server loopback options (table_name 'loct3', use_remote_estimate 'true');
|
2013-03-14 00:46:31 +01:00
|
|
|
|
|
|
|
-- can be sent to remote
|
|
|
|
explain (verbose, costs off) select * from ft3 where f1 = 'foo';
|
|
|
|
explain (verbose, costs off) select * from ft3 where f1 COLLATE "C" = 'foo';
|
|
|
|
explain (verbose, costs off) select * from ft3 where f2 = 'foo';
|
Improve handling of collations in contrib/postgres_fdw.
If we have a local Var of say varchar type with default collation, and
we apply a RelabelType to convert that to text with default collation, we
don't want to consider that as creating an FDW_COLLATE_UNSAFE situation.
It should be okay to compare that to a remote Var, so long as the remote
Var determines the comparison collation. (When we actually ship such an
expression to the remote side, the local Var would become a Param with
default collation, meaning the remote Var would in fact control the
comparison collation, because non-default implicit collation overrides
default implicit collation in parse_collate.c.) To fix, be more precise
about what FDW_COLLATE_NONE means: it applies either to a noncollatable
data type or to a collatable type with default collation, if that collation
can't be traced to a remote Var. (When it can, FDW_COLLATE_SAFE is
appropriate.) We were essentially using that interpretation already at
the Var/Const/Param level, but we weren't bubbling it up properly.
An alternative fix would be to introduce a separate FDW_COLLATE_DEFAULT
value to describe the second situation, but that would add more code
without changing the actual behavior, so it didn't seem worthwhile.
Also, since we're clarifying the rule to be that we care about whether
operator/function input collations match, there seems no need to fail
immediately upon seeing a Const/Param/non-foreign-Var with nondefault
collation. We only have to reject if it appears in a collation-sensitive
context (for example, "var IS NOT NULL" is perfectly safe from a collation
standpoint, whatever collation the var has). So just set the state to
UNSAFE rather than failing immediately.
Per report from Jeevan Chalke. This essentially corrects some sloppy
thinking in commit ed3ddf918b59545583a4b374566bc1148e75f593, so back-patch
to 9.3 where that logic appeared.
2015-09-24 18:47:29 +02:00
|
|
|
explain (verbose, costs off) select * from ft3 where f3 = 'foo';
|
|
|
|
explain (verbose, costs off) select * from ft3 f, loct3 l
|
|
|
|
where f.f3 = l.f3 and l.f1 = 'foo';
|
2013-03-14 00:46:31 +01:00
|
|
|
-- can't be sent to remote
|
|
|
|
explain (verbose, costs off) select * from ft3 where f1 COLLATE "POSIX" = 'foo';
|
|
|
|
explain (verbose, costs off) select * from ft3 where f1 = 'foo' COLLATE "C";
|
|
|
|
explain (verbose, costs off) select * from ft3 where f2 COLLATE "C" = 'foo';
|
|
|
|
explain (verbose, costs off) select * from ft3 where f2 = 'foo' COLLATE "C";
|
Improve handling of collations in contrib/postgres_fdw.
If we have a local Var of say varchar type with default collation, and
we apply a RelabelType to convert that to text with default collation, we
don't want to consider that as creating an FDW_COLLATE_UNSAFE situation.
It should be okay to compare that to a remote Var, so long as the remote
Var determines the comparison collation. (When we actually ship such an
expression to the remote side, the local Var would become a Param with
default collation, meaning the remote Var would in fact control the
comparison collation, because non-default implicit collation overrides
default implicit collation in parse_collate.c.) To fix, be more precise
about what FDW_COLLATE_NONE means: it applies either to a noncollatable
data type or to a collatable type with default collation, if that collation
can't be traced to a remote Var. (When it can, FDW_COLLATE_SAFE is
appropriate.) We were essentially using that interpretation already at
the Var/Const/Param level, but we weren't bubbling it up properly.
An alternative fix would be to introduce a separate FDW_COLLATE_DEFAULT
value to describe the second situation, but that would add more code
without changing the actual behavior, so it didn't seem worthwhile.
Also, since we're clarifying the rule to be that we care about whether
operator/function input collations match, there seems no need to fail
immediately upon seeing a Const/Param/non-foreign-Var with nondefault
collation. We only have to reject if it appears in a collation-sensitive
context (for example, "var IS NOT NULL" is perfectly safe from a collation
standpoint, whatever collation the var has). So just set the state to
UNSAFE rather than failing immediately.
Per report from Jeevan Chalke. This essentially corrects some sloppy
thinking in commit ed3ddf918b59545583a4b374566bc1148e75f593, so back-patch
to 9.3 where that logic appeared.
2015-09-24 18:47:29 +02:00
|
|
|
explain (verbose, costs off) select * from ft3 f, loct3 l
|
|
|
|
where f.f3 = l.f3 COLLATE "POSIX" and l.f1 = 'foo';
|
2013-03-14 00:46:31 +01:00
|
|
|
|
2013-03-10 19:14:53 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- test writable foreign table stuff
|
|
|
|
-- ===================================================================
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
INSERT INTO ft2 (c1,c2,c3) SELECT c1+1000,c2+100, c3 || c3 FROM ft2 LIMIT 20;
|
|
|
|
INSERT INTO ft2 (c1,c2,c3) SELECT c1+1000,c2+100, c3 || c3 FROM ft2 LIMIT 20;
|
|
|
|
INSERT INTO ft2 (c1,c2,c3)
|
|
|
|
VALUES (1101,201,'aaa'), (1102,202,'bbb'), (1103,203,'ccc') RETURNING *;
|
|
|
|
INSERT INTO ft2 (c1,c2,c3) VALUES (1104,204,'ddd'), (1105,205,'eee');
|
2016-03-18 18:48:58 +01:00
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE ft2 SET c2 = c2 + 300, c3 = c3 || '_update3' WHERE c1 % 10 = 3; -- can be pushed down
|
2013-03-10 19:14:53 +01:00
|
|
|
UPDATE ft2 SET c2 = c2 + 300, c3 = c3 || '_update3' WHERE c1 % 10 = 3;
|
2016-03-18 18:48:58 +01:00
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE ft2 SET c2 = c2 + 400, c3 = c3 || '_update7' WHERE c1 % 10 = 7 RETURNING *; -- can be pushed down
|
2013-03-10 19:14:53 +01:00
|
|
|
UPDATE ft2 SET c2 = c2 + 400, c3 = c3 || '_update7' WHERE c1 % 10 = 7 RETURNING *;
|
|
|
|
EXPLAIN (verbose, costs off)
|
2013-03-12 23:58:13 +01:00
|
|
|
UPDATE ft2 SET c2 = ft2.c2 + 500, c3 = ft2.c3 || '_update9', c7 = DEFAULT
|
postgres_fdw: Push down UPDATE/DELETE joins to remote servers.
Commit 0bf3ae88af330496517722e391e7c975e6bad219 allowed direct
foreign table modification; instead of fetching each row, updating
it locally, and then pushing the modification back to the remote
side, we would instead do all the work on the remote server via a
single remote UPDATE or DELETE command. However, that commit only
enabled this optimization when join tree consisted only of the
target table.
This change allows the same optimization when an UPDATE statement
has a FROM clause or a DELETE statement has a USING clause. This
works much like ordinary foreign join pushdown, in that the tables
must be on the same remote server, relevant parts of the query
must be pushdown-safe, and so forth.
Etsuro Fujita, reviewed by Ashutosh Bapat, Rushabh Lathia, and me.
Some formatting corrections by me.
Discussion: http://postgr.es/m/5A57193A.2080003@lab.ntt.co.jp
Discussion: http://postgr.es/m/b9cee735-62f8-6c07-7528-6364ce9347d0@lab.ntt.co.jp
2018-02-07 21:34:30 +01:00
|
|
|
FROM ft1 WHERE ft1.c1 = ft2.c2 AND ft1.c1 % 10 = 9; -- can be pushed down
|
2013-03-12 23:58:13 +01:00
|
|
|
UPDATE ft2 SET c2 = ft2.c2 + 500, c3 = ft2.c3 || '_update9', c7 = DEFAULT
|
2013-03-10 19:14:53 +01:00
|
|
|
FROM ft1 WHERE ft1.c1 = ft2.c2 AND ft1.c1 % 10 = 9;
|
2013-03-22 05:31:11 +01:00
|
|
|
EXPLAIN (verbose, costs off)
|
2016-03-18 18:48:58 +01:00
|
|
|
DELETE FROM ft2 WHERE c1 % 10 = 5 RETURNING c1, c4; -- can be pushed down
|
2013-03-22 05:31:11 +01:00
|
|
|
DELETE FROM ft2 WHERE c1 % 10 = 5 RETURNING c1, c4;
|
2013-03-10 19:14:53 +01:00
|
|
|
EXPLAIN (verbose, costs off)
|
postgres_fdw: Push down UPDATE/DELETE joins to remote servers.
Commit 0bf3ae88af330496517722e391e7c975e6bad219 allowed direct
foreign table modification; instead of fetching each row, updating
it locally, and then pushing the modification back to the remote
side, we would instead do all the work on the remote server via a
single remote UPDATE or DELETE command. However, that commit only
enabled this optimization when join tree consisted only of the
target table.
This change allows the same optimization when an UPDATE statement
has a FROM clause or a DELETE statement has a USING clause. This
works much like ordinary foreign join pushdown, in that the tables
must be on the same remote server, relevant parts of the query
must be pushdown-safe, and so forth.
Etsuro Fujita, reviewed by Ashutosh Bapat, Rushabh Lathia, and me.
Some formatting corrections by me.
Discussion: http://postgr.es/m/5A57193A.2080003@lab.ntt.co.jp
Discussion: http://postgr.es/m/b9cee735-62f8-6c07-7528-6364ce9347d0@lab.ntt.co.jp
2018-02-07 21:34:30 +01:00
|
|
|
DELETE FROM ft2 USING ft1 WHERE ft1.c1 = ft2.c2 AND ft1.c1 % 10 = 2; -- can be pushed down
|
2013-03-10 19:14:53 +01:00
|
|
|
DELETE FROM ft2 USING ft1 WHERE ft1.c1 = ft2.c2 AND ft1.c1 % 10 = 2;
|
|
|
|
SELECT c1,c2,c3,c4 FROM ft2 ORDER BY c1;
|
2016-02-05 04:15:50 +01:00
|
|
|
EXPLAIN (verbose, costs off)
|
2018-04-12 21:12:06 +02:00
|
|
|
INSERT INTO ft2 (c1,c2,c3) VALUES (1200,999,'foo') RETURNING tableoid::regclass;
|
|
|
|
INSERT INTO ft2 (c1,c2,c3) VALUES (1200,999,'foo') RETURNING tableoid::regclass;
|
2016-02-05 04:15:50 +01:00
|
|
|
EXPLAIN (verbose, costs off)
|
2018-04-12 21:12:06 +02:00
|
|
|
UPDATE ft2 SET c3 = 'bar' WHERE c1 = 1200 RETURNING tableoid::regclass; -- can be pushed down
|
|
|
|
UPDATE ft2 SET c3 = 'bar' WHERE c1 = 1200 RETURNING tableoid::regclass;
|
2016-02-05 04:15:50 +01:00
|
|
|
EXPLAIN (verbose, costs off)
|
2018-04-12 21:12:06 +02:00
|
|
|
DELETE FROM ft2 WHERE c1 = 1200 RETURNING tableoid::regclass; -- can be pushed down
|
|
|
|
DELETE FROM ft2 WHERE c1 = 1200 RETURNING tableoid::regclass;
|
2013-03-10 19:14:53 +01:00
|
|
|
|
postgres_fdw: Push down UPDATE/DELETE joins to remote servers.
Commit 0bf3ae88af330496517722e391e7c975e6bad219 allowed direct
foreign table modification; instead of fetching each row, updating
it locally, and then pushing the modification back to the remote
side, we would instead do all the work on the remote server via a
single remote UPDATE or DELETE command. However, that commit only
enabled this optimization when join tree consisted only of the
target table.
This change allows the same optimization when an UPDATE statement
has a FROM clause or a DELETE statement has a USING clause. This
works much like ordinary foreign join pushdown, in that the tables
must be on the same remote server, relevant parts of the query
must be pushdown-safe, and so forth.
Etsuro Fujita, reviewed by Ashutosh Bapat, Rushabh Lathia, and me.
Some formatting corrections by me.
Discussion: http://postgr.es/m/5A57193A.2080003@lab.ntt.co.jp
Discussion: http://postgr.es/m/b9cee735-62f8-6c07-7528-6364ce9347d0@lab.ntt.co.jp
2018-02-07 21:34:30 +01:00
|
|
|
-- Test UPDATE/DELETE with RETURNING on a three-table join
|
|
|
|
INSERT INTO ft2 (c1,c2,c3)
|
|
|
|
SELECT id, id - 1200, to_char(id, 'FM00000') FROM generate_series(1201, 1300) id;
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE ft2 SET c3 = 'foo'
|
|
|
|
FROM ft4 INNER JOIN ft5 ON (ft4.c1 = ft5.c1)
|
|
|
|
WHERE ft2.c1 > 1200 AND ft2.c2 = ft4.c1
|
2018-02-08 02:38:08 +01:00
|
|
|
RETURNING ft2, ft2.*, ft4, ft4.*; -- can be pushed down
|
postgres_fdw: Push down UPDATE/DELETE joins to remote servers.
Commit 0bf3ae88af330496517722e391e7c975e6bad219 allowed direct
foreign table modification; instead of fetching each row, updating
it locally, and then pushing the modification back to the remote
side, we would instead do all the work on the remote server via a
single remote UPDATE or DELETE command. However, that commit only
enabled this optimization when join tree consisted only of the
target table.
This change allows the same optimization when an UPDATE statement
has a FROM clause or a DELETE statement has a USING clause. This
works much like ordinary foreign join pushdown, in that the tables
must be on the same remote server, relevant parts of the query
must be pushdown-safe, and so forth.
Etsuro Fujita, reviewed by Ashutosh Bapat, Rushabh Lathia, and me.
Some formatting corrections by me.
Discussion: http://postgr.es/m/5A57193A.2080003@lab.ntt.co.jp
Discussion: http://postgr.es/m/b9cee735-62f8-6c07-7528-6364ce9347d0@lab.ntt.co.jp
2018-02-07 21:34:30 +01:00
|
|
|
UPDATE ft2 SET c3 = 'foo'
|
|
|
|
FROM ft4 INNER JOIN ft5 ON (ft4.c1 = ft5.c1)
|
|
|
|
WHERE ft2.c1 > 1200 AND ft2.c2 = ft4.c1
|
2018-02-08 02:38:08 +01:00
|
|
|
RETURNING ft2, ft2.*, ft4, ft4.*;
|
postgres_fdw: Push down UPDATE/DELETE joins to remote servers.
Commit 0bf3ae88af330496517722e391e7c975e6bad219 allowed direct
foreign table modification; instead of fetching each row, updating
it locally, and then pushing the modification back to the remote
side, we would instead do all the work on the remote server via a
single remote UPDATE or DELETE command. However, that commit only
enabled this optimization when join tree consisted only of the
target table.
This change allows the same optimization when an UPDATE statement
has a FROM clause or a DELETE statement has a USING clause. This
works much like ordinary foreign join pushdown, in that the tables
must be on the same remote server, relevant parts of the query
must be pushdown-safe, and so forth.
Etsuro Fujita, reviewed by Ashutosh Bapat, Rushabh Lathia, and me.
Some formatting corrections by me.
Discussion: http://postgr.es/m/5A57193A.2080003@lab.ntt.co.jp
Discussion: http://postgr.es/m/b9cee735-62f8-6c07-7528-6364ce9347d0@lab.ntt.co.jp
2018-02-07 21:34:30 +01:00
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
DELETE FROM ft2
|
|
|
|
USING ft4 LEFT JOIN ft5 ON (ft4.c1 = ft5.c1)
|
|
|
|
WHERE ft2.c1 > 1200 AND ft2.c1 % 10 = 0 AND ft2.c2 = ft4.c1
|
2018-02-08 02:38:08 +01:00
|
|
|
RETURNING 100; -- can be pushed down
|
postgres_fdw: Push down UPDATE/DELETE joins to remote servers.
Commit 0bf3ae88af330496517722e391e7c975e6bad219 allowed direct
foreign table modification; instead of fetching each row, updating
it locally, and then pushing the modification back to the remote
side, we would instead do all the work on the remote server via a
single remote UPDATE or DELETE command. However, that commit only
enabled this optimization when join tree consisted only of the
target table.
This change allows the same optimization when an UPDATE statement
has a FROM clause or a DELETE statement has a USING clause. This
works much like ordinary foreign join pushdown, in that the tables
must be on the same remote server, relevant parts of the query
must be pushdown-safe, and so forth.
Etsuro Fujita, reviewed by Ashutosh Bapat, Rushabh Lathia, and me.
Some formatting corrections by me.
Discussion: http://postgr.es/m/5A57193A.2080003@lab.ntt.co.jp
Discussion: http://postgr.es/m/b9cee735-62f8-6c07-7528-6364ce9347d0@lab.ntt.co.jp
2018-02-07 21:34:30 +01:00
|
|
|
DELETE FROM ft2
|
|
|
|
USING ft4 LEFT JOIN ft5 ON (ft4.c1 = ft5.c1)
|
|
|
|
WHERE ft2.c1 > 1200 AND ft2.c1 % 10 = 0 AND ft2.c2 = ft4.c1
|
|
|
|
RETURNING 100;
|
|
|
|
DELETE FROM ft2 WHERE ft2.c1 > 1200;
|
|
|
|
|
In postgres_fdw, don't try to ship MULTIEXPR updates to remote server.
In a statement like "UPDATE remote_tab SET (x,y) = (SELECT ...)",
we'd conclude that the statement could be directly executed remotely,
because the sub-SELECT is in a resjunk tlist item that's not examined
for shippability. Currently that ends up crashing if the sub-SELECT
contains any remote Vars. Prevent the crash by deeming MULTIEXEC
Params to be unshippable.
This is a bit of a brute-force solution, since if the sub-SELECT
*doesn't* contain any remote Vars, the current execution technology
would work; but that's not a terribly common use-case for this syntax,
I think. In any case, we generally don't try to ship sub-SELECTs, so
it won't surprise anybody that this doesn't end up as a remote direct
update. I'd be inclined to see if that general limitation can be fixed
before worrying about this case further.
Per report from Lukáš Sobotka.
Back-patch to 9.6. 9.5 had MULTIEXPR, but we didn't try to perform
remote direct updates then, so the case didn't arise anyway.
Discussion: https://postgr.es/m/CAJif3k+iA_ekBB5Zw2hDBaE1wtiQa4LH4_JUXrrMGwTrH0J01Q@mail.gmail.com
2020-01-26 20:31:08 +01:00
|
|
|
-- Test UPDATE with a MULTIEXPR sub-select
|
|
|
|
-- (maybe someday this'll be remotely executable, but not today)
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE ft2 AS target SET (c2, c7) = (
|
|
|
|
SELECT c2 * 10, c7
|
|
|
|
FROM ft2 AS src
|
|
|
|
WHERE target.c1 = src.c1
|
|
|
|
) WHERE c1 > 1100;
|
|
|
|
UPDATE ft2 AS target SET (c2, c7) = (
|
|
|
|
SELECT c2 * 10, c7
|
|
|
|
FROM ft2 AS src
|
|
|
|
WHERE target.c1 = src.c1
|
|
|
|
) WHERE c1 > 1100;
|
|
|
|
|
|
|
|
UPDATE ft2 AS target SET (c2) = (
|
|
|
|
SELECT c2 / 10
|
|
|
|
FROM ft2 AS src
|
|
|
|
WHERE target.c1 = src.c1
|
|
|
|
) WHERE c1 > 1100;
|
|
|
|
|
2021-06-05 02:07:08 +02:00
|
|
|
-- Test UPDATE involving a join that can be pushed down,
|
|
|
|
-- but a SET clause that can't be
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
UPDATE ft2 d SET c2 = CASE WHEN random() >= 0 THEN d.c2 ELSE 0 END
|
2021-06-20 17:48:44 +02:00
|
|
|
FROM ft2 AS t WHERE d.c1 = t.c1 AND d.c1 > 1000;
|
2021-06-05 02:07:08 +02:00
|
|
|
UPDATE ft2 d SET c2 = CASE WHEN random() >= 0 THEN d.c2 ELSE 0 END
|
2021-06-20 17:48:44 +02:00
|
|
|
FROM ft2 AS t WHERE d.c1 = t.c1 AND d.c1 > 1000;
|
2021-06-05 02:07:08 +02:00
|
|
|
|
postgres_fdw: Push down UPDATE/DELETE joins to remote servers.
Commit 0bf3ae88af330496517722e391e7c975e6bad219 allowed direct
foreign table modification; instead of fetching each row, updating
it locally, and then pushing the modification back to the remote
side, we would instead do all the work on the remote server via a
single remote UPDATE or DELETE command. However, that commit only
enabled this optimization when join tree consisted only of the
target table.
This change allows the same optimization when an UPDATE statement
has a FROM clause or a DELETE statement has a USING clause. This
works much like ordinary foreign join pushdown, in that the tables
must be on the same remote server, relevant parts of the query
must be pushdown-safe, and so forth.
Etsuro Fujita, reviewed by Ashutosh Bapat, Rushabh Lathia, and me.
Some formatting corrections by me.
Discussion: http://postgr.es/m/5A57193A.2080003@lab.ntt.co.jp
Discussion: http://postgr.es/m/b9cee735-62f8-6c07-7528-6364ce9347d0@lab.ntt.co.jp
2018-02-07 21:34:30 +01:00
|
|
|
-- Test UPDATE/DELETE with WHERE or JOIN/ON conditions containing
|
|
|
|
-- user-defined operators/functions
|
|
|
|
ALTER SERVER loopback OPTIONS (DROP extensions);
|
|
|
|
INSERT INTO ft2 (c1,c2,c3)
|
|
|
|
SELECT id, id % 10, to_char(id, 'FM00000') FROM generate_series(2001, 2010) id;
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE ft2 SET c3 = 'bar' WHERE postgres_fdw_abs(c1) > 2000 RETURNING *; -- can't be pushed down
|
|
|
|
UPDATE ft2 SET c3 = 'bar' WHERE postgres_fdw_abs(c1) > 2000 RETURNING *;
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE ft2 SET c3 = 'baz'
|
|
|
|
FROM ft4 INNER JOIN ft5 ON (ft4.c1 = ft5.c1)
|
|
|
|
WHERE ft2.c1 > 2000 AND ft2.c2 === ft4.c1
|
|
|
|
RETURNING ft2.*, ft4.*, ft5.*; -- can't be pushed down
|
|
|
|
UPDATE ft2 SET c3 = 'baz'
|
|
|
|
FROM ft4 INNER JOIN ft5 ON (ft4.c1 = ft5.c1)
|
|
|
|
WHERE ft2.c1 > 2000 AND ft2.c2 === ft4.c1
|
|
|
|
RETURNING ft2.*, ft4.*, ft5.*;
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
DELETE FROM ft2
|
|
|
|
USING ft4 INNER JOIN ft5 ON (ft4.c1 === ft5.c1)
|
|
|
|
WHERE ft2.c1 > 2000 AND ft2.c2 = ft4.c1
|
2018-02-08 02:38:08 +01:00
|
|
|
RETURNING ft2.c1, ft2.c2, ft2.c3; -- can't be pushed down
|
postgres_fdw: Push down UPDATE/DELETE joins to remote servers.
Commit 0bf3ae88af330496517722e391e7c975e6bad219 allowed direct
foreign table modification; instead of fetching each row, updating
it locally, and then pushing the modification back to the remote
side, we would instead do all the work on the remote server via a
single remote UPDATE or DELETE command. However, that commit only
enabled this optimization when join tree consisted only of the
target table.
This change allows the same optimization when an UPDATE statement
has a FROM clause or a DELETE statement has a USING clause. This
works much like ordinary foreign join pushdown, in that the tables
must be on the same remote server, relevant parts of the query
must be pushdown-safe, and so forth.
Etsuro Fujita, reviewed by Ashutosh Bapat, Rushabh Lathia, and me.
Some formatting corrections by me.
Discussion: http://postgr.es/m/5A57193A.2080003@lab.ntt.co.jp
Discussion: http://postgr.es/m/b9cee735-62f8-6c07-7528-6364ce9347d0@lab.ntt.co.jp
2018-02-07 21:34:30 +01:00
|
|
|
DELETE FROM ft2
|
|
|
|
USING ft4 INNER JOIN ft5 ON (ft4.c1 === ft5.c1)
|
|
|
|
WHERE ft2.c1 > 2000 AND ft2.c2 = ft4.c1
|
2018-02-08 02:38:08 +01:00
|
|
|
RETURNING ft2.c1, ft2.c2, ft2.c3;
|
postgres_fdw: Push down UPDATE/DELETE joins to remote servers.
Commit 0bf3ae88af330496517722e391e7c975e6bad219 allowed direct
foreign table modification; instead of fetching each row, updating
it locally, and then pushing the modification back to the remote
side, we would instead do all the work on the remote server via a
single remote UPDATE or DELETE command. However, that commit only
enabled this optimization when join tree consisted only of the
target table.
This change allows the same optimization when an UPDATE statement
has a FROM clause or a DELETE statement has a USING clause. This
works much like ordinary foreign join pushdown, in that the tables
must be on the same remote server, relevant parts of the query
must be pushdown-safe, and so forth.
Etsuro Fujita, reviewed by Ashutosh Bapat, Rushabh Lathia, and me.
Some formatting corrections by me.
Discussion: http://postgr.es/m/5A57193A.2080003@lab.ntt.co.jp
Discussion: http://postgr.es/m/b9cee735-62f8-6c07-7528-6364ce9347d0@lab.ntt.co.jp
2018-02-07 21:34:30 +01:00
|
|
|
DELETE FROM ft2 WHERE ft2.c1 > 2000;
|
|
|
|
ALTER SERVER loopback OPTIONS (ADD extensions 'postgres_fdw');
|
|
|
|
|
2013-03-12 23:58:13 +01:00
|
|
|
-- Test that trigger on remote table works as expected
|
2013-03-10 19:14:53 +01:00
|
|
|
CREATE OR REPLACE FUNCTION "S 1".F_BRTRIG() RETURNS trigger AS $$
|
|
|
|
BEGIN
|
|
|
|
NEW.c3 = NEW.c3 || '_trig_update';
|
|
|
|
RETURN NEW;
|
|
|
|
END;
|
|
|
|
$$ LANGUAGE plpgsql;
|
|
|
|
CREATE TRIGGER t1_br_insert BEFORE INSERT OR UPDATE
|
|
|
|
ON "S 1"."T 1" FOR EACH ROW EXECUTE PROCEDURE "S 1".F_BRTRIG();
|
|
|
|
|
2013-06-10 01:41:52 +02:00
|
|
|
INSERT INTO ft2 (c1,c2,c3) VALUES (1208, 818, 'fff') RETURNING *;
|
|
|
|
INSERT INTO ft2 (c1,c2,c3,c6) VALUES (1218, 818, 'ggg', '(--;') RETURNING *;
|
|
|
|
UPDATE ft2 SET c2 = c2 + 600 WHERE c1 % 10 = 8 AND c1 < 1200 RETURNING *;
|
2013-03-10 19:14:53 +01:00
|
|
|
|
|
|
|
-- Test errors thrown on remote side during update
|
|
|
|
ALTER TABLE "S 1"."T 1" ADD CONSTRAINT c2positive CHECK (c2 >= 0);
|
|
|
|
|
|
|
|
INSERT INTO ft1(c1, c2) VALUES(11, 12); -- duplicate key
|
Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE.
The newly added ON CONFLICT clause allows to specify an alternative to
raising a unique or exclusion constraint violation error when inserting.
ON CONFLICT refers to constraints that can either be specified using a
inference clause (by specifying the columns of a unique constraint) or
by naming a unique or exclusion constraint. DO NOTHING avoids the
constraint violation, without touching the pre-existing row. DO UPDATE
SET ... [WHERE ...] updates the pre-existing tuple, and has access to
both the tuple proposed for insertion and the existing tuple; the
optional WHERE clause can be used to prevent an update from being
executed. The UPDATE SET and WHERE clauses have access to the tuple
proposed for insertion using the "magic" EXCLUDED alias, and to the
pre-existing tuple using the table name or its alias.
This feature is often referred to as upsert.
This is implemented using a new infrastructure called "speculative
insertion". It is an optimistic variant of regular insertion that first
does a pre-check for existing tuples and then attempts an insert. If a
violating tuple was inserted concurrently, the speculatively inserted
tuple is deleted and a new attempt is made. If the pre-check finds a
matching tuple the alternative DO NOTHING or DO UPDATE action is taken.
If the insertion succeeds without detecting a conflict, the tuple is
deemed inserted.
To handle the possible ambiguity between the excluded alias and a table
named excluded, and for convenience with long relation names, INSERT
INTO now can alias its target table.
Bumps catversion as stored rules change.
Author: Peter Geoghegan, with significant contributions from Heikki
Linnakangas and Andres Freund. Testing infrastructure by Jeff Janes.
Reviewed-By: Heikki Linnakangas, Andres Freund, Robert Haas, Simon Riggs,
Dean Rasheed, Stephen Frost and many others.
2015-05-08 05:31:36 +02:00
|
|
|
INSERT INTO ft1(c1, c2) VALUES(11, 12) ON CONFLICT DO NOTHING; -- works
|
|
|
|
INSERT INTO ft1(c1, c2) VALUES(11, 12) ON CONFLICT (c1, c2) DO NOTHING; -- unsupported
|
|
|
|
INSERT INTO ft1(c1, c2) VALUES(11, 12) ON CONFLICT (c1, c2) DO UPDATE SET c3 = 'ffg'; -- unsupported
|
2013-03-10 19:14:53 +01:00
|
|
|
INSERT INTO ft1(c1, c2) VALUES(1111, -2); -- c2positive
|
2013-03-12 02:31:28 +01:00
|
|
|
UPDATE ft1 SET c2 = -c2 WHERE c1 = 1; -- c2positive
|
2013-03-10 19:14:53 +01:00
|
|
|
|
|
|
|
-- Test savepoint/rollback behavior
|
|
|
|
select c2, count(*) from ft2 where c2 < 500 group by 1 order by 1;
|
|
|
|
select c2, count(*) from "S 1"."T 1" where c2 < 500 group by 1 order by 1;
|
|
|
|
begin;
|
|
|
|
update ft2 set c2 = 42 where c2 = 0;
|
|
|
|
select c2, count(*) from ft2 where c2 < 500 group by 1 order by 1;
|
|
|
|
savepoint s1;
|
|
|
|
update ft2 set c2 = 44 where c2 = 4;
|
|
|
|
select c2, count(*) from ft2 where c2 < 500 group by 1 order by 1;
|
|
|
|
release savepoint s1;
|
|
|
|
select c2, count(*) from ft2 where c2 < 500 group by 1 order by 1;
|
|
|
|
savepoint s2;
|
|
|
|
update ft2 set c2 = 46 where c2 = 6;
|
|
|
|
select c2, count(*) from ft2 where c2 < 500 group by 1 order by 1;
|
|
|
|
rollback to savepoint s2;
|
|
|
|
select c2, count(*) from ft2 where c2 < 500 group by 1 order by 1;
|
|
|
|
release savepoint s2;
|
|
|
|
select c2, count(*) from ft2 where c2 < 500 group by 1 order by 1;
|
|
|
|
savepoint s3;
|
2013-03-12 15:47:04 +01:00
|
|
|
update ft2 set c2 = -2 where c2 = 42 and c1 = 10; -- fail on remote side
|
2013-03-10 19:14:53 +01:00
|
|
|
rollback to savepoint s3;
|
|
|
|
select c2, count(*) from ft2 where c2 < 500 group by 1 order by 1;
|
|
|
|
release savepoint s3;
|
|
|
|
select c2, count(*) from ft2 where c2 < 500 group by 1 order by 1;
|
|
|
|
-- none of the above is committed yet remotely
|
|
|
|
select c2, count(*) from "S 1"."T 1" where c2 < 500 group by 1 order by 1;
|
|
|
|
commit;
|
|
|
|
select c2, count(*) from ft2 where c2 < 500 group by 1 order by 1;
|
|
|
|
select c2, count(*) from "S 1"."T 1" where c2 < 500 group by 1 order by 1;
|
2013-05-16 01:03:29 +02:00
|
|
|
|
2018-02-09 21:24:35 +01:00
|
|
|
VACUUM ANALYZE "S 1"."T 1";
|
|
|
|
|
2016-03-04 17:35:46 +01:00
|
|
|
-- Above DMLs add data with c6 as NULL in ft1, so test ORDER BY NULLS LAST and NULLs
|
|
|
|
-- FIRST behavior here.
|
|
|
|
-- ORDER BY DESC NULLS LAST options
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 ORDER BY c6 DESC NULLS LAST, c1 OFFSET 795 LIMIT 10;
|
2016-03-04 17:35:46 +01:00
|
|
|
SELECT * FROM ft1 ORDER BY c6 DESC NULLS LAST, c1 OFFSET 795 LIMIT 10;
|
|
|
|
-- ORDER BY DESC NULLS FIRST options
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 ORDER BY c6 DESC NULLS FIRST, c1 OFFSET 15 LIMIT 10;
|
2016-03-04 17:35:46 +01:00
|
|
|
SELECT * FROM ft1 ORDER BY c6 DESC NULLS FIRST, c1 OFFSET 15 LIMIT 10;
|
|
|
|
-- ORDER BY ASC NULLS FIRST options
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM ft1 ORDER BY c6 ASC NULLS FIRST, c1 OFFSET 15 LIMIT 10;
|
2016-03-04 17:35:46 +01:00
|
|
|
SELECT * FROM ft1 ORDER BY c6 ASC NULLS FIRST, c1 OFFSET 15 LIMIT 10;
|
|
|
|
|
2014-12-17 23:00:53 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- test check constraints
|
|
|
|
-- ===================================================================
|
|
|
|
|
|
|
|
-- Consistent check constraints provide consistent results
|
|
|
|
ALTER FOREIGN TABLE ft1 ADD CONSTRAINT ft1_c2positive CHECK (c2 >= 0);
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT count(*) FROM ft1 WHERE c2 < 0;
|
2014-12-17 23:00:53 +01:00
|
|
|
SELECT count(*) FROM ft1 WHERE c2 < 0;
|
|
|
|
SET constraint_exclusion = 'on';
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT count(*) FROM ft1 WHERE c2 < 0;
|
2014-12-17 23:00:53 +01:00
|
|
|
SELECT count(*) FROM ft1 WHERE c2 < 0;
|
|
|
|
RESET constraint_exclusion;
|
|
|
|
-- check constraint is enforced on the remote side, not locally
|
|
|
|
INSERT INTO ft1(c1, c2) VALUES(1111, -2); -- c2positive
|
|
|
|
UPDATE ft1 SET c2 = -c2 WHERE c1 = 1; -- c2positive
|
|
|
|
ALTER FOREIGN TABLE ft1 DROP CONSTRAINT ft1_c2positive;
|
|
|
|
|
|
|
|
-- But inconsistent check constraints provide inconsistent results
|
|
|
|
ALTER FOREIGN TABLE ft1 ADD CONSTRAINT ft1_c2negative CHECK (c2 < 0);
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT count(*) FROM ft1 WHERE c2 >= 0;
|
2014-12-17 23:00:53 +01:00
|
|
|
SELECT count(*) FROM ft1 WHERE c2 >= 0;
|
|
|
|
SET constraint_exclusion = 'on';
|
Avoid invalidating all foreign-join cached plans when user mappings change.
We must not push down a foreign join when the foreign tables involved
should be accessed under different user mappings. Previously we tried
to enforce that rule literally during planning, but that meant that the
resulting plans were dependent on the current contents of the
pg_user_mapping catalog, and we had to blow away all cached plans
containing any remote join when anything at all changed in pg_user_mapping.
This could have been improved somewhat, but the fact that a syscache inval
callback has very limited info about what changed made it hard to do better
within that design. Instead, let's change the planner to not consider user
mappings per se, but to allow a foreign join if both RTEs have the same
checkAsUser value. If they do, then they necessarily will use the same
user mapping at runtime, and we don't need to know specifically which one
that is. Post-plan-time changes in pg_user_mapping no longer require any
plan invalidation.
This rule does give up some optimization ability, to wit where two foreign
table references come from views with different owners or one's from a view
and one's directly in the query, but nonetheless the same user mapping
would have applied. We'll sacrifice the first case, but to not regress
more than we have to in the second case, allow a foreign join involving
both zero and nonzero checkAsUser values if the nonzero one is the same as
the prevailing effective userID. In that case, mark the plan as only
runnable by that userID.
The plancache code already had a notion of plans being userID-specific,
in order to support RLS. It was a little confused though, in particular
lacking clarity of thought as to whether it was the rewritten query or just
the finished plan that's dependent on the userID. Rearrange that code so
that it's clearer what depends on which, and so that the same logic applies
to both RLS-injected role dependency and foreign-join-injected role
dependency.
Note that this patch doesn't remove the other issue mentioned in the
original complaint, which is that while we'll reliably stop using a foreign
join if it's disallowed in a new context, we might fail to start using a
foreign join if it's now allowed, but we previously created a generic
cached plan that didn't use one. It was agreed that the chance of winning
that way was not high enough to justify the much larger number of plan
invalidations that would have to occur if we tried to cause it to happen.
In passing, clean up randomly-varying spelling of EXPLAIN commands in
postgres_fdw.sql, and fix a COSTS ON example that had been allowed to
leak into the committed tests.
This reverts most of commits fbe5a3fb7 and 5d4171d1c, which were the
previous attempt at ensuring we wouldn't push down foreign joins that
span permissions contexts.
Etsuro Fujita and Tom Lane
Discussion: <d49c1e5b-f059-20f4-c132-e9752ee0113e@lab.ntt.co.jp>
2016-07-15 23:22:56 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) SELECT count(*) FROM ft1 WHERE c2 >= 0;
|
2014-12-17 23:00:53 +01:00
|
|
|
SELECT count(*) FROM ft1 WHERE c2 >= 0;
|
|
|
|
RESET constraint_exclusion;
|
|
|
|
-- local check constraint is not actually enforced
|
|
|
|
INSERT INTO ft1(c1, c2) VALUES(1111, 2);
|
|
|
|
UPDATE ft1 SET c2 = c2 + 1 WHERE c1 = 1;
|
|
|
|
ALTER FOREIGN TABLE ft1 DROP CONSTRAINT ft1_c2negative;
|
|
|
|
|
2013-05-16 01:03:29 +02:00
|
|
|
-- ===================================================================
|
2017-07-24 21:57:24 +02:00
|
|
|
-- test WITH CHECK OPTION constraints
|
|
|
|
-- ===================================================================
|
|
|
|
|
Fix WITH CHECK OPTION on views referencing postgres_fdw tables.
If a view references a foreign table, and the foreign table has a
BEFORE INSERT trigger, then it's possible for a tuple inserted or
updated through the view to be changed such that it violates the
view's WITH CHECK OPTION constraint.
Before this commit, postgres_fdw handled this case inconsistently. A
RETURNING clause on the INSERT or UPDATE statement targeting the view
would cause the finally-inserted tuple to be read back, and the WITH
CHECK OPTION violation would throw an error. But without a RETURNING
clause, postgres_fdw would not read the final tuple back, and WITH
CHECK OPTION would not throw an error for the violation (or may throw
an error when there is no real violation). AFTER ROW triggers on the
foreign table had a similar effect as a RETURNING clause on the INSERT
or UPDATE statement.
To fix, this commit retrieves the attributes needed to enforce the
WITH CHECK OPTION constraint along with the attributes needed for the
RETURNING clause (if any) from the remote side. Thus, the WITH CHECK
OPTION constraint is always evaluated against the final tuple after
any triggers on the remote side.
This fix may be considered inconsistent with CHECK constraints
declared on foreign tables, which are not enforced locally at all
(because the constraint is on a remote object). The discussion
concluded that this difference is reasonable, because the WITH CHECK
OPTION is a constraint on the local view (not any remote object);
therefore it only makes sense to enforce its WITH CHECK OPTION
constraint locally.
Author: Etsuro Fujita
Reviewed-by: Arthur Zakirov, Stephen Frost
Discussion: https://www.postgresql.org/message-id/7eb58fab-fd3b-781b-ac33-f7cfec96021f%40lab.ntt.co.jp
2018-07-08 09:14:51 +02:00
|
|
|
CREATE FUNCTION row_before_insupd_trigfunc() RETURNS trigger AS $$BEGIN NEW.a := NEW.a + 10; RETURN NEW; END$$ LANGUAGE plpgsql;
|
|
|
|
|
2017-07-24 21:57:24 +02:00
|
|
|
CREATE TABLE base_tbl (a int, b int);
|
2018-03-02 19:16:01 +01:00
|
|
|
ALTER TABLE base_tbl SET (autovacuum_enabled = 'false');
|
Fix WITH CHECK OPTION on views referencing postgres_fdw tables.
If a view references a foreign table, and the foreign table has a
BEFORE INSERT trigger, then it's possible for a tuple inserted or
updated through the view to be changed such that it violates the
view's WITH CHECK OPTION constraint.
Before this commit, postgres_fdw handled this case inconsistently. A
RETURNING clause on the INSERT or UPDATE statement targeting the view
would cause the finally-inserted tuple to be read back, and the WITH
CHECK OPTION violation would throw an error. But without a RETURNING
clause, postgres_fdw would not read the final tuple back, and WITH
CHECK OPTION would not throw an error for the violation (or may throw
an error when there is no real violation). AFTER ROW triggers on the
foreign table had a similar effect as a RETURNING clause on the INSERT
or UPDATE statement.
To fix, this commit retrieves the attributes needed to enforce the
WITH CHECK OPTION constraint along with the attributes needed for the
RETURNING clause (if any) from the remote side. Thus, the WITH CHECK
OPTION constraint is always evaluated against the final tuple after
any triggers on the remote side.
This fix may be considered inconsistent with CHECK constraints
declared on foreign tables, which are not enforced locally at all
(because the constraint is on a remote object). The discussion
concluded that this difference is reasonable, because the WITH CHECK
OPTION is a constraint on the local view (not any remote object);
therefore it only makes sense to enforce its WITH CHECK OPTION
constraint locally.
Author: Etsuro Fujita
Reviewed-by: Arthur Zakirov, Stephen Frost
Discussion: https://www.postgresql.org/message-id/7eb58fab-fd3b-781b-ac33-f7cfec96021f%40lab.ntt.co.jp
2018-07-08 09:14:51 +02:00
|
|
|
CREATE TRIGGER row_before_insupd_trigger BEFORE INSERT OR UPDATE ON base_tbl FOR EACH ROW EXECUTE PROCEDURE row_before_insupd_trigfunc();
|
2017-07-24 21:57:24 +02:00
|
|
|
CREATE FOREIGN TABLE foreign_tbl (a int, b int)
|
Fix WITH CHECK OPTION on views referencing postgres_fdw tables.
If a view references a foreign table, and the foreign table has a
BEFORE INSERT trigger, then it's possible for a tuple inserted or
updated through the view to be changed such that it violates the
view's WITH CHECK OPTION constraint.
Before this commit, postgres_fdw handled this case inconsistently. A
RETURNING clause on the INSERT or UPDATE statement targeting the view
would cause the finally-inserted tuple to be read back, and the WITH
CHECK OPTION violation would throw an error. But without a RETURNING
clause, postgres_fdw would not read the final tuple back, and WITH
CHECK OPTION would not throw an error for the violation (or may throw
an error when there is no real violation). AFTER ROW triggers on the
foreign table had a similar effect as a RETURNING clause on the INSERT
or UPDATE statement.
To fix, this commit retrieves the attributes needed to enforce the
WITH CHECK OPTION constraint along with the attributes needed for the
RETURNING clause (if any) from the remote side. Thus, the WITH CHECK
OPTION constraint is always evaluated against the final tuple after
any triggers on the remote side.
This fix may be considered inconsistent with CHECK constraints
declared on foreign tables, which are not enforced locally at all
(because the constraint is on a remote object). The discussion
concluded that this difference is reasonable, because the WITH CHECK
OPTION is a constraint on the local view (not any remote object);
therefore it only makes sense to enforce its WITH CHECK OPTION
constraint locally.
Author: Etsuro Fujita
Reviewed-by: Arthur Zakirov, Stephen Frost
Discussion: https://www.postgresql.org/message-id/7eb58fab-fd3b-781b-ac33-f7cfec96021f%40lab.ntt.co.jp
2018-07-08 09:14:51 +02:00
|
|
|
SERVER loopback OPTIONS (table_name 'base_tbl');
|
2017-07-24 21:57:24 +02:00
|
|
|
CREATE VIEW rw_view AS SELECT * FROM foreign_tbl
|
|
|
|
WHERE a < b WITH CHECK OPTION;
|
|
|
|
\d+ rw_view
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
Fix WITH CHECK OPTION on views referencing postgres_fdw tables.
If a view references a foreign table, and the foreign table has a
BEFORE INSERT trigger, then it's possible for a tuple inserted or
updated through the view to be changed such that it violates the
view's WITH CHECK OPTION constraint.
Before this commit, postgres_fdw handled this case inconsistently. A
RETURNING clause on the INSERT or UPDATE statement targeting the view
would cause the finally-inserted tuple to be read back, and the WITH
CHECK OPTION violation would throw an error. But without a RETURNING
clause, postgres_fdw would not read the final tuple back, and WITH
CHECK OPTION would not throw an error for the violation (or may throw
an error when there is no real violation). AFTER ROW triggers on the
foreign table had a similar effect as a RETURNING clause on the INSERT
or UPDATE statement.
To fix, this commit retrieves the attributes needed to enforce the
WITH CHECK OPTION constraint along with the attributes needed for the
RETURNING clause (if any) from the remote side. Thus, the WITH CHECK
OPTION constraint is always evaluated against the final tuple after
any triggers on the remote side.
This fix may be considered inconsistent with CHECK constraints
declared on foreign tables, which are not enforced locally at all
(because the constraint is on a remote object). The discussion
concluded that this difference is reasonable, because the WITH CHECK
OPTION is a constraint on the local view (not any remote object);
therefore it only makes sense to enforce its WITH CHECK OPTION
constraint locally.
Author: Etsuro Fujita
Reviewed-by: Arthur Zakirov, Stephen Frost
Discussion: https://www.postgresql.org/message-id/7eb58fab-fd3b-781b-ac33-f7cfec96021f%40lab.ntt.co.jp
2018-07-08 09:14:51 +02:00
|
|
|
INSERT INTO rw_view VALUES (0, 5);
|
|
|
|
INSERT INTO rw_view VALUES (0, 5); -- should fail
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO rw_view VALUES (0, 15);
|
|
|
|
INSERT INTO rw_view VALUES (0, 15); -- ok
|
|
|
|
SELECT * FROM foreign_tbl;
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
UPDATE rw_view SET b = b + 5;
|
|
|
|
UPDATE rw_view SET b = b + 5; -- should fail
|
2017-07-24 21:57:24 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
Fix WITH CHECK OPTION on views referencing postgres_fdw tables.
If a view references a foreign table, and the foreign table has a
BEFORE INSERT trigger, then it's possible for a tuple inserted or
updated through the view to be changed such that it violates the
view's WITH CHECK OPTION constraint.
Before this commit, postgres_fdw handled this case inconsistently. A
RETURNING clause on the INSERT or UPDATE statement targeting the view
would cause the finally-inserted tuple to be read back, and the WITH
CHECK OPTION violation would throw an error. But without a RETURNING
clause, postgres_fdw would not read the final tuple back, and WITH
CHECK OPTION would not throw an error for the violation (or may throw
an error when there is no real violation). AFTER ROW triggers on the
foreign table had a similar effect as a RETURNING clause on the INSERT
or UPDATE statement.
To fix, this commit retrieves the attributes needed to enforce the
WITH CHECK OPTION constraint along with the attributes needed for the
RETURNING clause (if any) from the remote side. Thus, the WITH CHECK
OPTION constraint is always evaluated against the final tuple after
any triggers on the remote side.
This fix may be considered inconsistent with CHECK constraints
declared on foreign tables, which are not enforced locally at all
(because the constraint is on a remote object). The discussion
concluded that this difference is reasonable, because the WITH CHECK
OPTION is a constraint on the local view (not any remote object);
therefore it only makes sense to enforce its WITH CHECK OPTION
constraint locally.
Author: Etsuro Fujita
Reviewed-by: Arthur Zakirov, Stephen Frost
Discussion: https://www.postgresql.org/message-id/7eb58fab-fd3b-781b-ac33-f7cfec96021f%40lab.ntt.co.jp
2018-07-08 09:14:51 +02:00
|
|
|
UPDATE rw_view SET b = b + 15;
|
|
|
|
UPDATE rw_view SET b = b + 15; -- ok
|
2017-07-24 21:57:24 +02:00
|
|
|
SELECT * FROM foreign_tbl;
|
|
|
|
|
2022-08-05 10:15:00 +02:00
|
|
|
-- We don't allow batch insert when there are any WCO constraints
|
|
|
|
ALTER SERVER loopback OPTIONS (ADD batch_size '10');
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO rw_view VALUES (0, 15), (0, 5);
|
|
|
|
INSERT INTO rw_view VALUES (0, 15), (0, 5); -- should fail
|
|
|
|
SELECT * FROM foreign_tbl;
|
|
|
|
ALTER SERVER loopback OPTIONS (DROP batch_size);
|
|
|
|
|
2017-07-24 21:57:24 +02:00
|
|
|
DROP FOREIGN TABLE foreign_tbl CASCADE;
|
Fix WITH CHECK OPTION on views referencing postgres_fdw tables.
If a view references a foreign table, and the foreign table has a
BEFORE INSERT trigger, then it's possible for a tuple inserted or
updated through the view to be changed such that it violates the
view's WITH CHECK OPTION constraint.
Before this commit, postgres_fdw handled this case inconsistently. A
RETURNING clause on the INSERT or UPDATE statement targeting the view
would cause the finally-inserted tuple to be read back, and the WITH
CHECK OPTION violation would throw an error. But without a RETURNING
clause, postgres_fdw would not read the final tuple back, and WITH
CHECK OPTION would not throw an error for the violation (or may throw
an error when there is no real violation). AFTER ROW triggers on the
foreign table had a similar effect as a RETURNING clause on the INSERT
or UPDATE statement.
To fix, this commit retrieves the attributes needed to enforce the
WITH CHECK OPTION constraint along with the attributes needed for the
RETURNING clause (if any) from the remote side. Thus, the WITH CHECK
OPTION constraint is always evaluated against the final tuple after
any triggers on the remote side.
This fix may be considered inconsistent with CHECK constraints
declared on foreign tables, which are not enforced locally at all
(because the constraint is on a remote object). The discussion
concluded that this difference is reasonable, because the WITH CHECK
OPTION is a constraint on the local view (not any remote object);
therefore it only makes sense to enforce its WITH CHECK OPTION
constraint locally.
Author: Etsuro Fujita
Reviewed-by: Arthur Zakirov, Stephen Frost
Discussion: https://www.postgresql.org/message-id/7eb58fab-fd3b-781b-ac33-f7cfec96021f%40lab.ntt.co.jp
2018-07-08 09:14:51 +02:00
|
|
|
DROP TRIGGER row_before_insupd_trigger ON base_tbl;
|
2017-07-24 21:57:24 +02:00
|
|
|
DROP TABLE base_tbl;
|
|
|
|
|
Fix WITH CHECK OPTION on views referencing postgres_fdw tables.
If a view references a foreign table, and the foreign table has a
BEFORE INSERT trigger, then it's possible for a tuple inserted or
updated through the view to be changed such that it violates the
view's WITH CHECK OPTION constraint.
Before this commit, postgres_fdw handled this case inconsistently. A
RETURNING clause on the INSERT or UPDATE statement targeting the view
would cause the finally-inserted tuple to be read back, and the WITH
CHECK OPTION violation would throw an error. But without a RETURNING
clause, postgres_fdw would not read the final tuple back, and WITH
CHECK OPTION would not throw an error for the violation (or may throw
an error when there is no real violation). AFTER ROW triggers on the
foreign table had a similar effect as a RETURNING clause on the INSERT
or UPDATE statement.
To fix, this commit retrieves the attributes needed to enforce the
WITH CHECK OPTION constraint along with the attributes needed for the
RETURNING clause (if any) from the remote side. Thus, the WITH CHECK
OPTION constraint is always evaluated against the final tuple after
any triggers on the remote side.
This fix may be considered inconsistent with CHECK constraints
declared on foreign tables, which are not enforced locally at all
(because the constraint is on a remote object). The discussion
concluded that this difference is reasonable, because the WITH CHECK
OPTION is a constraint on the local view (not any remote object);
therefore it only makes sense to enforce its WITH CHECK OPTION
constraint locally.
Author: Etsuro Fujita
Reviewed-by: Arthur Zakirov, Stephen Frost
Discussion: https://www.postgresql.org/message-id/7eb58fab-fd3b-781b-ac33-f7cfec96021f%40lab.ntt.co.jp
2018-07-08 09:14:51 +02:00
|
|
|
-- test WCO for partitions
|
|
|
|
|
|
|
|
CREATE TABLE child_tbl (a int, b int);
|
|
|
|
ALTER TABLE child_tbl SET (autovacuum_enabled = 'false');
|
|
|
|
CREATE TRIGGER row_before_insupd_trigger BEFORE INSERT OR UPDATE ON child_tbl FOR EACH ROW EXECUTE PROCEDURE row_before_insupd_trigfunc();
|
|
|
|
CREATE FOREIGN TABLE foreign_tbl (a int, b int)
|
|
|
|
SERVER loopback OPTIONS (table_name 'child_tbl');
|
|
|
|
|
|
|
|
CREATE TABLE parent_tbl (a int, b int) PARTITION BY RANGE(a);
|
|
|
|
ALTER TABLE parent_tbl ATTACH PARTITION foreign_tbl FOR VALUES FROM (0) TO (100);
|
Remove assertion for ALTER TABLE .. DETACH PARTITION CONCURRENTLY
One code path related to this flavor of ALTER TABLE was checking that
the relation to detach has to be a normal table or a partitioned table,
which would fail if using the command with a different relation kind.
Views, sequences and materialized views cannot be part of a partition
tree, so these would cause the command to fail anyway, but the assertion
was triggered. Foreign tables can be part of a partition tree, and
again the assertion would have failed. The simplest solution is just to
remove this assertion, so as we get the same failure as the
non-concurrent code path.
While on it, add a regression test in postgres_fdw for the concurrent
partition detach of a foreign table, as per a suggestion from Alexander
Lakhin.
Issue introduced in 71f4c8c.
Reported-by: Alexander Lakhin
Author: Michael Paquier, Alexander Lakhin
Reviewed-by: Peter Eisentraut, Kyotaro Horiguchi
Discussion: https://postgr.es/m/17339-a9e09aaf38a3457a@postgresql.org
Backpatch-through: 14
2021-12-22 07:38:00 +01:00
|
|
|
-- Detach and re-attach once, to stress the concurrent detach case.
|
|
|
|
ALTER TABLE parent_tbl DETACH PARTITION foreign_tbl CONCURRENTLY;
|
|
|
|
ALTER TABLE parent_tbl ATTACH PARTITION foreign_tbl FOR VALUES FROM (0) TO (100);
|
Fix WITH CHECK OPTION on views referencing postgres_fdw tables.
If a view references a foreign table, and the foreign table has a
BEFORE INSERT trigger, then it's possible for a tuple inserted or
updated through the view to be changed such that it violates the
view's WITH CHECK OPTION constraint.
Before this commit, postgres_fdw handled this case inconsistently. A
RETURNING clause on the INSERT or UPDATE statement targeting the view
would cause the finally-inserted tuple to be read back, and the WITH
CHECK OPTION violation would throw an error. But without a RETURNING
clause, postgres_fdw would not read the final tuple back, and WITH
CHECK OPTION would not throw an error for the violation (or may throw
an error when there is no real violation). AFTER ROW triggers on the
foreign table had a similar effect as a RETURNING clause on the INSERT
or UPDATE statement.
To fix, this commit retrieves the attributes needed to enforce the
WITH CHECK OPTION constraint along with the attributes needed for the
RETURNING clause (if any) from the remote side. Thus, the WITH CHECK
OPTION constraint is always evaluated against the final tuple after
any triggers on the remote side.
This fix may be considered inconsistent with CHECK constraints
declared on foreign tables, which are not enforced locally at all
(because the constraint is on a remote object). The discussion
concluded that this difference is reasonable, because the WITH CHECK
OPTION is a constraint on the local view (not any remote object);
therefore it only makes sense to enforce its WITH CHECK OPTION
constraint locally.
Author: Etsuro Fujita
Reviewed-by: Arthur Zakirov, Stephen Frost
Discussion: https://www.postgresql.org/message-id/7eb58fab-fd3b-781b-ac33-f7cfec96021f%40lab.ntt.co.jp
2018-07-08 09:14:51 +02:00
|
|
|
|
|
|
|
CREATE VIEW rw_view AS SELECT * FROM parent_tbl
|
|
|
|
WHERE a < b WITH CHECK OPTION;
|
|
|
|
\d+ rw_view
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO rw_view VALUES (0, 5);
|
|
|
|
INSERT INTO rw_view VALUES (0, 5); -- should fail
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO rw_view VALUES (0, 15);
|
|
|
|
INSERT INTO rw_view VALUES (0, 15); -- ok
|
|
|
|
SELECT * FROM foreign_tbl;
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
UPDATE rw_view SET b = b + 5;
|
|
|
|
UPDATE rw_view SET b = b + 5; -- should fail
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
UPDATE rw_view SET b = b + 15;
|
|
|
|
UPDATE rw_view SET b = b + 15; -- ok
|
|
|
|
SELECT * FROM foreign_tbl;
|
|
|
|
|
2022-08-05 10:15:00 +02:00
|
|
|
-- We don't allow batch insert when there are any WCO constraints
|
|
|
|
ALTER SERVER loopback OPTIONS (ADD batch_size '10');
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO rw_view VALUES (0, 15), (0, 5);
|
|
|
|
INSERT INTO rw_view VALUES (0, 15), (0, 5); -- should fail
|
|
|
|
SELECT * FROM foreign_tbl;
|
|
|
|
ALTER SERVER loopback OPTIONS (DROP batch_size);
|
|
|
|
|
Fix WITH CHECK OPTION on views referencing postgres_fdw tables.
If a view references a foreign table, and the foreign table has a
BEFORE INSERT trigger, then it's possible for a tuple inserted or
updated through the view to be changed such that it violates the
view's WITH CHECK OPTION constraint.
Before this commit, postgres_fdw handled this case inconsistently. A
RETURNING clause on the INSERT or UPDATE statement targeting the view
would cause the finally-inserted tuple to be read back, and the WITH
CHECK OPTION violation would throw an error. But without a RETURNING
clause, postgres_fdw would not read the final tuple back, and WITH
CHECK OPTION would not throw an error for the violation (or may throw
an error when there is no real violation). AFTER ROW triggers on the
foreign table had a similar effect as a RETURNING clause on the INSERT
or UPDATE statement.
To fix, this commit retrieves the attributes needed to enforce the
WITH CHECK OPTION constraint along with the attributes needed for the
RETURNING clause (if any) from the remote side. Thus, the WITH CHECK
OPTION constraint is always evaluated against the final tuple after
any triggers on the remote side.
This fix may be considered inconsistent with CHECK constraints
declared on foreign tables, which are not enforced locally at all
(because the constraint is on a remote object). The discussion
concluded that this difference is reasonable, because the WITH CHECK
OPTION is a constraint on the local view (not any remote object);
therefore it only makes sense to enforce its WITH CHECK OPTION
constraint locally.
Author: Etsuro Fujita
Reviewed-by: Arthur Zakirov, Stephen Frost
Discussion: https://www.postgresql.org/message-id/7eb58fab-fd3b-781b-ac33-f7cfec96021f%40lab.ntt.co.jp
2018-07-08 09:14:51 +02:00
|
|
|
DROP FOREIGN TABLE foreign_tbl CASCADE;
|
|
|
|
DROP TRIGGER row_before_insupd_trigger ON child_tbl;
|
|
|
|
DROP TABLE parent_tbl CASCADE;
|
|
|
|
|
|
|
|
DROP FUNCTION row_before_insupd_trigfunc;
|
|
|
|
|
2022-12-23 12:58:34 +01:00
|
|
|
-- Try a more complex permutation of WCO where there are multiple levels of
|
|
|
|
-- partitioned tables with columns not all in the same order
|
|
|
|
CREATE TABLE parent_tbl (a int, b text, c numeric) PARTITION BY RANGE(a);
|
|
|
|
CREATE TABLE sub_parent (c numeric, a int, b text) PARTITION BY RANGE(a);
|
|
|
|
ALTER TABLE parent_tbl ATTACH PARTITION sub_parent FOR VALUES FROM (1) TO (10);
|
|
|
|
CREATE TABLE child_local (b text, c numeric, a int);
|
|
|
|
CREATE FOREIGN TABLE child_foreign (b text, c numeric, a int)
|
|
|
|
SERVER loopback OPTIONS (table_name 'child_local');
|
|
|
|
ALTER TABLE sub_parent ATTACH PARTITION child_foreign FOR VALUES FROM (1) TO (10);
|
|
|
|
CREATE VIEW rw_view AS SELECT * FROM parent_tbl WHERE a < 5 WITH CHECK OPTION;
|
|
|
|
|
|
|
|
INSERT INTO parent_tbl (a) VALUES(1),(5);
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
UPDATE rw_view SET b = 'text', c = 123.456;
|
|
|
|
UPDATE rw_view SET b = 'text', c = 123.456;
|
|
|
|
SELECT * FROM parent_tbl ORDER BY a;
|
|
|
|
|
|
|
|
DROP VIEW rw_view;
|
|
|
|
DROP TABLE child_local;
|
|
|
|
DROP FOREIGN TABLE child_foreign;
|
|
|
|
DROP TABLE sub_parent;
|
|
|
|
DROP TABLE parent_tbl;
|
|
|
|
|
2017-07-24 21:57:24 +02:00
|
|
|
-- ===================================================================
|
2013-05-16 01:03:29 +02:00
|
|
|
-- test serial columns (ie, sequence-based defaults)
|
|
|
|
-- ===================================================================
|
|
|
|
create table loc1 (f1 serial, f2 text);
|
2018-03-02 19:16:01 +01:00
|
|
|
alter table loc1 set (autovacuum_enabled = 'false');
|
2013-05-16 01:03:29 +02:00
|
|
|
create foreign table rem1 (f1 serial, f2 text)
|
|
|
|
server loopback options(table_name 'loc1');
|
|
|
|
select pg_catalog.setval('rem1_f1_seq', 10, false);
|
|
|
|
insert into loc1(f2) values('hi');
|
|
|
|
insert into rem1(f2) values('hi remote');
|
|
|
|
insert into loc1(f2) values('bye');
|
|
|
|
insert into rem1(f2) values('bye remote');
|
|
|
|
select * from loc1;
|
|
|
|
select * from rem1;
|
2014-03-23 07:16:34 +01:00
|
|
|
|
2019-03-30 08:13:09 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- test generated columns
|
|
|
|
-- ===================================================================
|
2021-08-05 13:00:00 +02:00
|
|
|
create table gloc1 (
|
|
|
|
a int,
|
|
|
|
b int generated always as (a * 2) stored);
|
2019-03-30 08:13:09 +01:00
|
|
|
alter table gloc1 set (autovacuum_enabled = 'false');
|
|
|
|
create foreign table grem1 (
|
|
|
|
a int,
|
|
|
|
b int generated always as (a * 2) stored)
|
|
|
|
server loopback options(table_name 'gloc1');
|
2021-08-05 13:00:00 +02:00
|
|
|
explain (verbose, costs off)
|
2019-03-30 08:13:09 +01:00
|
|
|
insert into grem1 (a) values (1), (2);
|
2021-08-05 13:00:00 +02:00
|
|
|
insert into grem1 (a) values (1), (2);
|
|
|
|
explain (verbose, costs off)
|
2019-03-30 08:13:09 +01:00
|
|
|
update grem1 set a = 22 where a = 2;
|
2021-08-05 13:00:00 +02:00
|
|
|
update grem1 set a = 22 where a = 2;
|
|
|
|
select * from gloc1;
|
|
|
|
select * from grem1;
|
|
|
|
delete from grem1;
|
|
|
|
|
|
|
|
-- test copy from
|
|
|
|
copy grem1 from stdin;
|
|
|
|
1
|
|
|
|
2
|
|
|
|
\.
|
|
|
|
select * from gloc1;
|
|
|
|
select * from grem1;
|
|
|
|
delete from grem1;
|
|
|
|
|
|
|
|
-- test batch insert
|
|
|
|
alter server loopback options (add batch_size '10');
|
|
|
|
explain (verbose, costs off)
|
|
|
|
insert into grem1 (a) values (1), (2);
|
|
|
|
insert into grem1 (a) values (1), (2);
|
2019-03-30 08:13:09 +01:00
|
|
|
select * from gloc1;
|
|
|
|
select * from grem1;
|
2021-08-05 13:00:00 +02:00
|
|
|
delete from grem1;
|
2023-04-25 02:42:19 +02:00
|
|
|
-- batch insert with foreign partitions.
|
|
|
|
-- This schema uses two partitions, one local and one remote with a modulo
|
|
|
|
-- to loop across all of them in batches.
|
|
|
|
create table tab_batch_local (id int, data text);
|
|
|
|
insert into tab_batch_local select i, 'test'|| i from generate_series(1, 45) i;
|
|
|
|
create table tab_batch_sharded (id int, data text) partition by hash(id);
|
|
|
|
create table tab_batch_sharded_p0 partition of tab_batch_sharded
|
|
|
|
for values with (modulus 2, remainder 0);
|
|
|
|
create table tab_batch_sharded_p1_remote (id int, data text);
|
|
|
|
create foreign table tab_batch_sharded_p1 partition of tab_batch_sharded
|
|
|
|
for values with (modulus 2, remainder 1)
|
|
|
|
server loopback options (table_name 'tab_batch_sharded_p1_remote');
|
|
|
|
insert into tab_batch_sharded select * from tab_batch_local;
|
|
|
|
select count(*) from tab_batch_sharded;
|
|
|
|
drop table tab_batch_local;
|
|
|
|
drop table tab_batch_sharded;
|
|
|
|
drop table tab_batch_sharded_p1_remote;
|
|
|
|
|
2021-08-05 13:00:00 +02:00
|
|
|
alter server loopback options (drop batch_size);
|
2019-03-30 08:13:09 +01:00
|
|
|
|
2014-03-23 07:16:34 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- test local triggers
|
|
|
|
-- ===================================================================
|
|
|
|
|
|
|
|
-- Trigger functions "borrowed" from triggers regress test.
|
|
|
|
CREATE FUNCTION trigger_func() RETURNS trigger LANGUAGE plpgsql AS $$
|
|
|
|
BEGIN
|
|
|
|
RAISE NOTICE 'trigger_func(%) called: action = %, when = %, level = %',
|
|
|
|
TG_ARGV[0], TG_OP, TG_WHEN, TG_LEVEL;
|
|
|
|
RETURN NULL;
|
|
|
|
END;$$;
|
|
|
|
|
2022-07-12 02:18:02 +02:00
|
|
|
CREATE TRIGGER trig_stmt_before BEFORE DELETE OR INSERT OR UPDATE OR TRUNCATE ON rem1
|
2014-03-23 07:16:34 +01:00
|
|
|
FOR EACH STATEMENT EXECUTE PROCEDURE trigger_func();
|
2022-07-12 02:18:02 +02:00
|
|
|
CREATE TRIGGER trig_stmt_after AFTER DELETE OR INSERT OR UPDATE OR TRUNCATE ON rem1
|
2014-03-23 07:16:34 +01:00
|
|
|
FOR EACH STATEMENT EXECUTE PROCEDURE trigger_func();
|
|
|
|
|
|
|
|
CREATE OR REPLACE FUNCTION trigger_data() RETURNS trigger
|
|
|
|
LANGUAGE plpgsql AS $$
|
|
|
|
|
|
|
|
declare
|
|
|
|
oldnew text[];
|
|
|
|
relid text;
|
|
|
|
argstr text;
|
|
|
|
begin
|
|
|
|
|
|
|
|
relid := TG_relid::regclass;
|
|
|
|
argstr := '';
|
|
|
|
for i in 0 .. TG_nargs - 1 loop
|
|
|
|
if i > 0 then
|
|
|
|
argstr := argstr || ', ';
|
|
|
|
end if;
|
|
|
|
argstr := argstr || TG_argv[i];
|
|
|
|
end loop;
|
|
|
|
|
|
|
|
RAISE NOTICE '%(%) % % % ON %',
|
|
|
|
tg_name, argstr, TG_when, TG_level, TG_OP, relid;
|
|
|
|
oldnew := '{}'::text[];
|
|
|
|
if TG_OP != 'INSERT' then
|
|
|
|
oldnew := array_append(oldnew, format('OLD: %s', OLD));
|
|
|
|
end if;
|
|
|
|
|
|
|
|
if TG_OP != 'DELETE' then
|
|
|
|
oldnew := array_append(oldnew, format('NEW: %s', NEW));
|
|
|
|
end if;
|
|
|
|
|
|
|
|
RAISE NOTICE '%', array_to_string(oldnew, ',');
|
|
|
|
|
|
|
|
if TG_OP = 'DELETE' then
|
|
|
|
return OLD;
|
|
|
|
else
|
|
|
|
return NEW;
|
|
|
|
end if;
|
|
|
|
end;
|
|
|
|
$$;
|
|
|
|
|
|
|
|
-- Test basic functionality
|
|
|
|
CREATE TRIGGER trig_row_before
|
|
|
|
BEFORE INSERT OR UPDATE OR DELETE ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_row_after
|
|
|
|
AFTER INSERT OR UPDATE OR DELETE ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
|
|
|
|
delete from rem1;
|
|
|
|
insert into rem1 values(1,'insert');
|
|
|
|
update rem1 set f2 = 'update' where f1 = 1;
|
|
|
|
update rem1 set f2 = f2 || f2;
|
2022-07-12 02:18:02 +02:00
|
|
|
truncate rem1;
|
2014-03-23 07:16:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
-- cleanup
|
|
|
|
DROP TRIGGER trig_row_before ON rem1;
|
|
|
|
DROP TRIGGER trig_row_after ON rem1;
|
|
|
|
DROP TRIGGER trig_stmt_before ON rem1;
|
|
|
|
DROP TRIGGER trig_stmt_after ON rem1;
|
|
|
|
|
|
|
|
DELETE from rem1;
|
|
|
|
|
2019-12-10 10:00:30 +01:00
|
|
|
-- Test multiple AFTER ROW triggers on a foreign table
|
|
|
|
CREATE TRIGGER trig_row_after1
|
|
|
|
AFTER INSERT OR UPDATE OR DELETE ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_row_after2
|
|
|
|
AFTER INSERT OR UPDATE OR DELETE ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
|
|
|
|
insert into rem1 values(1,'insert');
|
|
|
|
update rem1 set f2 = 'update' where f1 = 1;
|
|
|
|
update rem1 set f2 = f2 || f2;
|
|
|
|
delete from rem1;
|
|
|
|
|
|
|
|
-- cleanup
|
|
|
|
DROP TRIGGER trig_row_after1 ON rem1;
|
|
|
|
DROP TRIGGER trig_row_after2 ON rem1;
|
2014-03-23 07:16:34 +01:00
|
|
|
|
|
|
|
-- Test WHEN conditions
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_row_before_insupd
|
|
|
|
BEFORE INSERT OR UPDATE ON rem1
|
|
|
|
FOR EACH ROW
|
|
|
|
WHEN (NEW.f2 like '%update%')
|
|
|
|
EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_row_after_insupd
|
|
|
|
AFTER INSERT OR UPDATE ON rem1
|
|
|
|
FOR EACH ROW
|
|
|
|
WHEN (NEW.f2 like '%update%')
|
|
|
|
EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
|
|
|
|
-- Insert or update not matching: nothing happens
|
|
|
|
INSERT INTO rem1 values(1, 'insert');
|
|
|
|
UPDATE rem1 set f2 = 'test';
|
|
|
|
|
|
|
|
-- Insert or update matching: triggers are fired
|
|
|
|
INSERT INTO rem1 values(2, 'update');
|
|
|
|
UPDATE rem1 set f2 = 'update update' where f1 = '2';
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_row_before_delete
|
|
|
|
BEFORE DELETE ON rem1
|
|
|
|
FOR EACH ROW
|
|
|
|
WHEN (OLD.f2 like '%update%')
|
|
|
|
EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_row_after_delete
|
|
|
|
AFTER DELETE ON rem1
|
|
|
|
FOR EACH ROW
|
|
|
|
WHEN (OLD.f2 like '%update%')
|
|
|
|
EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
|
|
|
|
-- Trigger is fired for f1=2, not for f1=1
|
|
|
|
DELETE FROM rem1;
|
|
|
|
|
|
|
|
-- cleanup
|
|
|
|
DROP TRIGGER trig_row_before_insupd ON rem1;
|
|
|
|
DROP TRIGGER trig_row_after_insupd ON rem1;
|
|
|
|
DROP TRIGGER trig_row_before_delete ON rem1;
|
|
|
|
DROP TRIGGER trig_row_after_delete ON rem1;
|
|
|
|
|
|
|
|
|
|
|
|
-- Test various RETURN statements in BEFORE triggers.
|
|
|
|
|
|
|
|
CREATE FUNCTION trig_row_before_insupdate() RETURNS TRIGGER AS $$
|
|
|
|
BEGIN
|
|
|
|
NEW.f2 := NEW.f2 || ' triggered !';
|
|
|
|
RETURN NEW;
|
|
|
|
END
|
|
|
|
$$ language plpgsql;
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_row_before_insupd
|
|
|
|
BEFORE INSERT OR UPDATE ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trig_row_before_insupdate();
|
|
|
|
|
|
|
|
-- The new values should have 'triggered' appended
|
|
|
|
INSERT INTO rem1 values(1, 'insert');
|
|
|
|
SELECT * from loc1;
|
|
|
|
INSERT INTO rem1 values(2, 'insert') RETURNING f2;
|
|
|
|
SELECT * from loc1;
|
|
|
|
UPDATE rem1 set f2 = '';
|
|
|
|
SELECT * from loc1;
|
|
|
|
UPDATE rem1 set f2 = 'skidoo' RETURNING f2;
|
|
|
|
SELECT * from loc1;
|
|
|
|
|
2019-06-13 10:59:09 +02:00
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE rem1 set f1 = 10; -- all columns should be transmitted
|
|
|
|
UPDATE rem1 set f1 = 10;
|
|
|
|
SELECT * from loc1;
|
|
|
|
|
2014-03-23 07:16:34 +01:00
|
|
|
DELETE FROM rem1;
|
|
|
|
|
|
|
|
-- Add a second trigger, to check that the changes are propagated correctly
|
|
|
|
-- from trigger to trigger
|
|
|
|
CREATE TRIGGER trig_row_before_insupd2
|
|
|
|
BEFORE INSERT OR UPDATE ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trig_row_before_insupdate();
|
|
|
|
|
|
|
|
INSERT INTO rem1 values(1, 'insert');
|
|
|
|
SELECT * from loc1;
|
|
|
|
INSERT INTO rem1 values(2, 'insert') RETURNING f2;
|
|
|
|
SELECT * from loc1;
|
|
|
|
UPDATE rem1 set f2 = '';
|
|
|
|
SELECT * from loc1;
|
|
|
|
UPDATE rem1 set f2 = 'skidoo' RETURNING f2;
|
|
|
|
SELECT * from loc1;
|
|
|
|
|
|
|
|
DROP TRIGGER trig_row_before_insupd ON rem1;
|
|
|
|
DROP TRIGGER trig_row_before_insupd2 ON rem1;
|
|
|
|
|
|
|
|
DELETE from rem1;
|
|
|
|
|
|
|
|
INSERT INTO rem1 VALUES (1, 'test');
|
|
|
|
|
|
|
|
-- Test with a trigger returning NULL
|
|
|
|
CREATE FUNCTION trig_null() RETURNS TRIGGER AS $$
|
|
|
|
BEGIN
|
|
|
|
RETURN NULL;
|
|
|
|
END
|
|
|
|
$$ language plpgsql;
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_null
|
|
|
|
BEFORE INSERT OR UPDATE OR DELETE ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trig_null();
|
|
|
|
|
|
|
|
-- Nothing should have changed.
|
|
|
|
INSERT INTO rem1 VALUES (2, 'test2');
|
|
|
|
|
|
|
|
SELECT * from loc1;
|
|
|
|
|
|
|
|
UPDATE rem1 SET f2 = 'test2';
|
|
|
|
|
|
|
|
SELECT * from loc1;
|
|
|
|
|
|
|
|
DELETE from rem1;
|
|
|
|
|
|
|
|
SELECT * from loc1;
|
|
|
|
|
|
|
|
DROP TRIGGER trig_null ON rem1;
|
|
|
|
DELETE from rem1;
|
|
|
|
|
|
|
|
-- Test a combination of local and remote triggers
|
|
|
|
CREATE TRIGGER trig_row_before
|
|
|
|
BEFORE INSERT OR UPDATE OR DELETE ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_row_after
|
|
|
|
AFTER INSERT OR UPDATE OR DELETE ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_local_before BEFORE INSERT OR UPDATE ON loc1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trig_row_before_insupdate();
|
|
|
|
|
|
|
|
INSERT INTO rem1(f2) VALUES ('test');
|
|
|
|
UPDATE rem1 SET f2 = 'testo';
|
|
|
|
|
2014-03-23 08:48:17 +01:00
|
|
|
-- Test returning a system attribute
|
|
|
|
INSERT INTO rem1(f2) VALUES ('test') RETURNING ctid;
|
2014-07-10 21:01:31 +02:00
|
|
|
|
2016-03-18 18:48:58 +01:00
|
|
|
-- cleanup
|
|
|
|
DROP TRIGGER trig_row_before ON rem1;
|
|
|
|
DROP TRIGGER trig_row_after ON rem1;
|
|
|
|
DROP TRIGGER trig_local_before ON loc1;
|
|
|
|
|
|
|
|
|
|
|
|
-- Test direct foreign table modification functionality
|
2021-07-07 21:21:25 +02:00
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
DELETE FROM rem1; -- can be pushed down
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
DELETE FROM rem1 WHERE false; -- currently can't be pushed down
|
2016-03-18 18:48:58 +01:00
|
|
|
|
|
|
|
-- Test with statement-level triggers
|
|
|
|
CREATE TRIGGER trig_stmt_before
|
|
|
|
BEFORE DELETE OR INSERT OR UPDATE ON rem1
|
|
|
|
FOR EACH STATEMENT EXECUTE PROCEDURE trigger_func();
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE rem1 set f2 = ''; -- can be pushed down
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
DELETE FROM rem1; -- can be pushed down
|
|
|
|
DROP TRIGGER trig_stmt_before ON rem1;
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_stmt_after
|
|
|
|
AFTER DELETE OR INSERT OR UPDATE ON rem1
|
|
|
|
FOR EACH STATEMENT EXECUTE PROCEDURE trigger_func();
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE rem1 set f2 = ''; -- can be pushed down
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
DELETE FROM rem1; -- can be pushed down
|
|
|
|
DROP TRIGGER trig_stmt_after ON rem1;
|
|
|
|
|
|
|
|
-- Test with row-level ON INSERT triggers
|
|
|
|
CREATE TRIGGER trig_row_before_insert
|
|
|
|
BEFORE INSERT ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE rem1 set f2 = ''; -- can be pushed down
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
DELETE FROM rem1; -- can be pushed down
|
|
|
|
DROP TRIGGER trig_row_before_insert ON rem1;
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_row_after_insert
|
|
|
|
AFTER INSERT ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE rem1 set f2 = ''; -- can be pushed down
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
DELETE FROM rem1; -- can be pushed down
|
|
|
|
DROP TRIGGER trig_row_after_insert ON rem1;
|
|
|
|
|
|
|
|
-- Test with row-level ON UPDATE triggers
|
|
|
|
CREATE TRIGGER trig_row_before_update
|
|
|
|
BEFORE UPDATE ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE rem1 set f2 = ''; -- can't be pushed down
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
DELETE FROM rem1; -- can be pushed down
|
|
|
|
DROP TRIGGER trig_row_before_update ON rem1;
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_row_after_update
|
|
|
|
AFTER UPDATE ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE rem1 set f2 = ''; -- can't be pushed down
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
DELETE FROM rem1; -- can be pushed down
|
|
|
|
DROP TRIGGER trig_row_after_update ON rem1;
|
|
|
|
|
|
|
|
-- Test with row-level ON DELETE triggers
|
|
|
|
CREATE TRIGGER trig_row_before_delete
|
|
|
|
BEFORE DELETE ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE rem1 set f2 = ''; -- can be pushed down
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
DELETE FROM rem1; -- can't be pushed down
|
|
|
|
DROP TRIGGER trig_row_before_delete ON rem1;
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_row_after_delete
|
|
|
|
AFTER DELETE ON rem1
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
UPDATE rem1 set f2 = ''; -- can be pushed down
|
|
|
|
EXPLAIN (verbose, costs off)
|
|
|
|
DELETE FROM rem1; -- can't be pushed down
|
|
|
|
DROP TRIGGER trig_row_after_delete ON rem1;
|
|
|
|
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- test inheritance features
|
|
|
|
-- ===================================================================
|
|
|
|
|
|
|
|
CREATE TABLE a (aa TEXT);
|
|
|
|
CREATE TABLE loct (aa TEXT, bb TEXT);
|
2018-03-02 19:16:01 +01:00
|
|
|
ALTER TABLE a SET (autovacuum_enabled = 'false');
|
|
|
|
ALTER TABLE loct SET (autovacuum_enabled = 'false');
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
CREATE FOREIGN TABLE b (bb TEXT) INHERITS (a)
|
|
|
|
SERVER loopback OPTIONS (table_name 'loct');
|
|
|
|
|
|
|
|
INSERT INTO a(aa) VALUES('aaa');
|
|
|
|
INSERT INTO a(aa) VALUES('aaaa');
|
|
|
|
INSERT INTO a(aa) VALUES('aaaaa');
|
|
|
|
|
|
|
|
INSERT INTO b(aa) VALUES('bbb');
|
|
|
|
INSERT INTO b(aa) VALUES('bbbb');
|
|
|
|
INSERT INTO b(aa) VALUES('bbbbb');
|
|
|
|
|
|
|
|
SELECT tableoid::regclass, * FROM a;
|
|
|
|
SELECT tableoid::regclass, * FROM b;
|
|
|
|
SELECT tableoid::regclass, * FROM ONLY a;
|
|
|
|
|
|
|
|
UPDATE a SET aa = 'zzzzzz' WHERE aa LIKE 'aaaa%';
|
|
|
|
|
|
|
|
SELECT tableoid::regclass, * FROM a;
|
|
|
|
SELECT tableoid::regclass, * FROM b;
|
|
|
|
SELECT tableoid::regclass, * FROM ONLY a;
|
|
|
|
|
|
|
|
UPDATE b SET aa = 'new';
|
|
|
|
|
|
|
|
SELECT tableoid::regclass, * FROM a;
|
|
|
|
SELECT tableoid::regclass, * FROM b;
|
|
|
|
SELECT tableoid::regclass, * FROM ONLY a;
|
|
|
|
|
|
|
|
UPDATE a SET aa = 'newtoo';
|
|
|
|
|
|
|
|
SELECT tableoid::regclass, * FROM a;
|
|
|
|
SELECT tableoid::regclass, * FROM b;
|
|
|
|
SELECT tableoid::regclass, * FROM ONLY a;
|
|
|
|
|
|
|
|
DELETE FROM a;
|
|
|
|
|
|
|
|
SELECT tableoid::regclass, * FROM a;
|
|
|
|
SELECT tableoid::regclass, * FROM b;
|
|
|
|
SELECT tableoid::regclass, * FROM ONLY a;
|
|
|
|
|
|
|
|
DROP TABLE a CASCADE;
|
|
|
|
DROP TABLE loct;
|
|
|
|
|
|
|
|
-- Check SELECT FOR UPDATE/SHARE with an inherited source table
|
|
|
|
create table loct1 (f1 int, f2 int, f3 int);
|
|
|
|
create table loct2 (f1 int, f2 int, f3 int);
|
|
|
|
|
2018-03-02 19:16:01 +01:00
|
|
|
alter table loct1 set (autovacuum_enabled = 'false');
|
|
|
|
alter table loct2 set (autovacuum_enabled = 'false');
|
|
|
|
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
create table foo (f1 int, f2 int);
|
|
|
|
create foreign table foo2 (f3 int) inherits (foo)
|
|
|
|
server loopback options (table_name 'loct1');
|
|
|
|
create table bar (f1 int, f2 int);
|
|
|
|
create foreign table bar2 (f3 int) inherits (bar)
|
|
|
|
server loopback options (table_name 'loct2');
|
|
|
|
|
2018-03-02 19:16:01 +01:00
|
|
|
alter table foo set (autovacuum_enabled = 'false');
|
|
|
|
alter table bar set (autovacuum_enabled = 'false');
|
|
|
|
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
insert into foo values(1,1);
|
|
|
|
insert into foo values(3,3);
|
|
|
|
insert into foo2 values(2,2,2);
|
|
|
|
insert into foo2 values(4,4,4);
|
|
|
|
insert into bar values(1,11);
|
|
|
|
insert into bar values(2,22);
|
|
|
|
insert into bar values(6,66);
|
|
|
|
insert into bar2 values(3,33,33);
|
|
|
|
insert into bar2 values(4,44,44);
|
|
|
|
insert into bar2 values(7,77,77);
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select * from bar where f1 in (select f1 from foo) for update;
|
|
|
|
select * from bar where f1 in (select f1 from foo) for update;
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select * from bar where f1 in (select f1 from foo) for share;
|
|
|
|
select * from bar where f1 in (select f1 from foo) for share;
|
|
|
|
|
2021-06-02 20:38:14 +02:00
|
|
|
-- Now check SELECT FOR UPDATE/SHARE with an inherited source table,
|
|
|
|
-- where the parent is itself a foreign table
|
|
|
|
create table loct4 (f1 int, f2 int, f3 int);
|
|
|
|
create foreign table foo2child (f3 int) inherits (foo2)
|
|
|
|
server loopback options (table_name 'loct4');
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select * from bar where f1 in (select f1 from foo2) for share;
|
|
|
|
select * from bar where f1 in (select f1 from foo2) for share;
|
|
|
|
|
|
|
|
drop foreign table foo2child;
|
|
|
|
|
|
|
|
-- And with a local child relation of the foreign table parent
|
|
|
|
create table foo2child (f3 int) inherits (foo2);
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select * from bar where f1 in (select f1 from foo2) for share;
|
|
|
|
select * from bar where f1 in (select f1 from foo2) for share;
|
|
|
|
|
|
|
|
drop table foo2child;
|
|
|
|
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
-- Check UPDATE with inherited target and an inherited source table
|
|
|
|
explain (verbose, costs off)
|
|
|
|
update bar set f2 = f2 + 100 where f1 in (select f1 from foo);
|
|
|
|
update bar set f2 = f2 + 100 where f1 in (select f1 from foo);
|
|
|
|
|
|
|
|
select tableoid::regclass, * from bar order by 1,2;
|
|
|
|
|
|
|
|
-- Check UPDATE with inherited target and an appendrel subquery
|
|
|
|
explain (verbose, costs off)
|
|
|
|
update bar set f2 = f2 + 100
|
|
|
|
from
|
|
|
|
( select f1 from foo union all select f1+3 from foo ) ss
|
|
|
|
where bar.f1 = ss.f1;
|
|
|
|
update bar set f2 = f2 + 100
|
|
|
|
from
|
|
|
|
( select f1 from foo union all select f1+3 from foo ) ss
|
|
|
|
where bar.f1 = ss.f1;
|
|
|
|
|
|
|
|
select tableoid::regclass, * from bar order by 1,2;
|
|
|
|
|
2015-12-22 19:46:40 +01:00
|
|
|
-- Test forcing the remote server to produce sorted data for a merge join,
|
|
|
|
-- but the foreign table is an inheritance child.
|
|
|
|
truncate table loct1;
|
|
|
|
truncate table only foo;
|
|
|
|
\set num_rows_foo 2000
|
|
|
|
insert into loct1 select generate_series(0, :num_rows_foo, 2), generate_series(0, :num_rows_foo, 2), generate_series(0, :num_rows_foo, 2);
|
|
|
|
insert into foo select generate_series(1, :num_rows_foo, 2), generate_series(1, :num_rows_foo, 2);
|
|
|
|
SET enable_hashjoin to false;
|
|
|
|
SET enable_nestloop to false;
|
|
|
|
alter foreign table foo2 options (use_remote_estimate 'true');
|
|
|
|
create index i_loct1_f1 on loct1(f1);
|
|
|
|
create index i_foo_f1 on foo(f1);
|
|
|
|
analyze foo;
|
|
|
|
analyze loct1;
|
|
|
|
-- inner join; expressions in the clauses appear in the equivalence class list
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select foo.f1, loct1.f1 from foo join loct1 on (foo.f1 = loct1.f1) order by foo.f2 offset 10 limit 10;
|
|
|
|
select foo.f1, loct1.f1 from foo join loct1 on (foo.f1 = loct1.f1) order by foo.f2 offset 10 limit 10;
|
|
|
|
-- outer join; expressions in the clauses do not appear in equivalence class
|
|
|
|
-- list but no output change as compared to the previous query
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select foo.f1, loct1.f1 from foo left join loct1 on (foo.f1 = loct1.f1) order by foo.f2 offset 10 limit 10;
|
|
|
|
select foo.f1, loct1.f1 from foo left join loct1 on (foo.f1 = loct1.f1) order by foo.f2 offset 10 limit 10;
|
|
|
|
RESET enable_hashjoin;
|
|
|
|
RESET enable_nestloop;
|
|
|
|
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
-- Test that WHERE CURRENT OF is not supported
|
|
|
|
begin;
|
|
|
|
declare c cursor for select * from bar where f1 = 7;
|
|
|
|
fetch from c;
|
|
|
|
update bar set f2 = null where current of c;
|
|
|
|
rollback;
|
|
|
|
|
2016-03-18 18:48:58 +01:00
|
|
|
explain (verbose, costs off)
|
|
|
|
delete from foo where f1 < 5 returning *;
|
|
|
|
delete from foo where f1 < 5 returning *;
|
|
|
|
explain (verbose, costs off)
|
|
|
|
update bar set f2 = f2 + 100 returning *;
|
|
|
|
update bar set f2 = f2 + 100 returning *;
|
|
|
|
|
Fix creation of resjunk tlist entries for inherited mixed UPDATE/DELETE.
rewriteTargetListUD's processing is dependent on the relkind of the query's
target table. That was fine at the time it was made to act that way, even
for queries on inheritance trees, because all tables in an inheritance tree
would necessarily be plain tables. However, the 9.5 feature addition
allowing some members of an inheritance tree to be foreign tables broke the
assumption that rewriteTargetListUD's output tlist could be applied to all
child tables with nothing more than column-number mapping. This led to
visible failures if foreign child tables had row-level triggers, and would
also break in cases where child tables belonged to FDWs that used methods
other than CTID for row identification.
To fix, delay running rewriteTargetListUD until after the planner has
expanded inheritance, so that it is applied separately to the (already
mapped) tlist for each child table. We can conveniently call it from
preprocess_targetlist. Refactor associated code slightly to avoid the
need to heap_open the target relation multiple times during
preprocess_targetlist. (The APIs remain a bit ugly, particularly around
the point of which steps scribble on parse->targetList and which don't.
But avoiding such scribbling would require a change in FDW callback APIs,
which is more pain than it's worth.)
Also fix ExecModifyTable to ensure that "tupleid" is reset to NULL when
we transition from rows providing a CTID to rows that don't. (That's
really an independent bug, but it manifests in much the same cases.)
Add a regression test checking one manifestation of this problem, which
was that row-level triggers on a foreign child table did not work right.
Back-patch to 9.5 where the problem was introduced.
Etsuro Fujita, reviewed by Ildus Kurbangaliev and Ashutosh Bapat
Discussion: https://postgr.es/m/20170514150525.0346ba72@postgrespro.ru
2017-11-27 23:53:56 +01:00
|
|
|
-- Test that UPDATE/DELETE with inherited target works with row-level triggers
|
|
|
|
CREATE TRIGGER trig_row_before
|
|
|
|
BEFORE UPDATE OR DELETE ON bar2
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
|
|
|
|
CREATE TRIGGER trig_row_after
|
|
|
|
AFTER UPDATE OR DELETE ON bar2
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
update bar set f2 = f2 + 100;
|
|
|
|
update bar set f2 = f2 + 100;
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
delete from bar where f2 < 400;
|
|
|
|
delete from bar where f2 < 400;
|
|
|
|
|
|
|
|
-- cleanup
|
Allow foreign tables to participate in inheritance.
Foreign tables can now be inheritance children, or parents. Much of the
system was already ready for this, but we had to fix a few things of
course, mostly in the area of planner and executor handling of row locks.
As side effects of this, allow foreign tables to have NOT VALID CHECK
constraints (and hence to accept ALTER ... VALIDATE CONSTRAINT), and to
accept ALTER SET STORAGE and ALTER SET WITH/WITHOUT OIDS. Continuing to
disallow these things would've required bizarre and inconsistent special
cases in inheritance behavior. Since foreign tables don't enforce CHECK
constraints anyway, a NOT VALID one is a complete no-op, but that doesn't
mean we shouldn't allow it. And it's possible that some FDWs might have
use for SET STORAGE or SET WITH OIDS, though doubtless they will be no-ops
for most.
An additional change in support of this is that when a ModifyTable node
has multiple target tables, they will all now be explicitly identified
in EXPLAIN output, for example:
Update on pt1 (cost=0.00..321.05 rows=3541 width=46)
Update on pt1
Foreign Update on ft1
Foreign Update on ft2
Update on child3
-> Seq Scan on pt1 (cost=0.00..0.00 rows=1 width=46)
-> Foreign Scan on ft1 (cost=100.00..148.03 rows=1170 width=46)
-> Foreign Scan on ft2 (cost=100.00..148.03 rows=1170 width=46)
-> Seq Scan on child3 (cost=0.00..25.00 rows=1200 width=46)
This was done mainly to provide an unambiguous place to attach "Remote SQL"
fields, but it is useful for inherited updates even when no foreign tables
are involved.
Shigeru Hanada and Etsuro Fujita, reviewed by Ashutosh Bapat and Kyotaro
Horiguchi, some additional hacking by me
2015-03-22 18:53:11 +01:00
|
|
|
drop table foo cascade;
|
|
|
|
drop table bar cascade;
|
|
|
|
drop table loct1;
|
|
|
|
drop table loct2;
|
|
|
|
|
2018-05-16 17:32:38 +02:00
|
|
|
-- Test pushing down UPDATE/DELETE joins to the remote server
|
|
|
|
create table parent (a int, b text);
|
|
|
|
create table loct1 (a int, b text);
|
|
|
|
create table loct2 (a int, b text);
|
|
|
|
create foreign table remt1 (a int, b text)
|
|
|
|
server loopback options (table_name 'loct1');
|
|
|
|
create foreign table remt2 (a int, b text)
|
|
|
|
server loopback options (table_name 'loct2');
|
|
|
|
alter foreign table remt1 inherit parent;
|
|
|
|
|
|
|
|
insert into remt1 values (1, 'foo');
|
|
|
|
insert into remt1 values (2, 'bar');
|
|
|
|
insert into remt2 values (1, 'foo');
|
|
|
|
insert into remt2 values (2, 'bar');
|
|
|
|
|
|
|
|
analyze remt1;
|
|
|
|
analyze remt2;
|
|
|
|
|
|
|
|
explain (verbose, costs off)
|
|
|
|
update parent set b = parent.b || remt2.b from remt2 where parent.a = remt2.a returning *;
|
|
|
|
update parent set b = parent.b || remt2.b from remt2 where parent.a = remt2.a returning *;
|
|
|
|
explain (verbose, costs off)
|
|
|
|
delete from parent using remt2 where parent.a = remt2.a returning parent;
|
|
|
|
delete from parent using remt2 where parent.a = remt2.a returning parent;
|
|
|
|
|
|
|
|
-- cleanup
|
|
|
|
drop foreign table remt1;
|
|
|
|
drop foreign table remt2;
|
|
|
|
drop table loct1;
|
|
|
|
drop table loct2;
|
|
|
|
drop table parent;
|
|
|
|
|
2018-04-07 01:16:11 +02:00
|
|
|
-- ===================================================================
|
|
|
|
-- test tuple routing for foreign-table partitions
|
|
|
|
-- ===================================================================
|
|
|
|
|
|
|
|
-- Test insert tuple routing
|
|
|
|
create table itrtest (a int, b text) partition by list (a);
|
|
|
|
create table loct1 (a int check (a in (1)), b text);
|
|
|
|
create foreign table remp1 (a int check (a in (1)), b text) server loopback options (table_name 'loct1');
|
|
|
|
create table loct2 (a int check (a in (2)), b text);
|
|
|
|
create foreign table remp2 (b text, a int check (a in (2))) server loopback options (table_name 'loct2');
|
|
|
|
alter table itrtest attach partition remp1 for values in (1);
|
|
|
|
alter table itrtest attach partition remp2 for values in (2);
|
|
|
|
|
|
|
|
insert into itrtest values (1, 'foo');
|
|
|
|
insert into itrtest values (1, 'bar') returning *;
|
|
|
|
insert into itrtest values (2, 'baz');
|
|
|
|
insert into itrtest values (2, 'qux') returning *;
|
|
|
|
insert into itrtest values (1, 'test1'), (2, 'test2') returning *;
|
|
|
|
|
|
|
|
select tableoid::regclass, * FROM itrtest;
|
|
|
|
select tableoid::regclass, * FROM remp1;
|
|
|
|
select tableoid::regclass, * FROM remp2;
|
|
|
|
|
|
|
|
delete from itrtest;
|
|
|
|
|
2022-10-15 19:24:26 +02:00
|
|
|
-- MERGE ought to fail cleanly
|
|
|
|
merge into itrtest using (select 1, 'foo') as source on (true)
|
|
|
|
when matched then do nothing;
|
|
|
|
|
2018-04-07 01:16:11 +02:00
|
|
|
create unique index loct1_idx on loct1 (a);
|
|
|
|
|
|
|
|
-- DO NOTHING without an inference specification is supported
|
|
|
|
insert into itrtest values (1, 'foo') on conflict do nothing returning *;
|
|
|
|
insert into itrtest values (1, 'foo') on conflict do nothing returning *;
|
|
|
|
|
|
|
|
-- But other cases are not supported
|
|
|
|
insert into itrtest values (1, 'bar') on conflict (a) do nothing;
|
|
|
|
insert into itrtest values (1, 'bar') on conflict (a) do update set b = excluded.b;
|
|
|
|
|
|
|
|
select tableoid::regclass, * FROM itrtest;
|
|
|
|
|
Fix interaction of foreign tuple routing with remote triggers.
Without these fixes, changes to the inserted tuple made by remote
triggers are ignored when building local RETURNING tuples.
In the core code, call ExecInitRoutingInfo at a later point from
within ExecInitPartitionInfo so that the FDW callback gets invoked
after the returning list has been built. But move CheckValidResultRel
out of ExecInitRoutingInfo so that it can happen at an earlier stage.
In postgres_fdw, refactor assorted deparsing functions to work with
the RTE rather than the PlannerInfo, which saves us having to
construct a fake PlannerInfo in cases where we don't have a real one.
Then, we can pass down a constructed RTE that yields the correct
deparse result when no real one exists. Unfortunately, this
necessitates a hack that understands how the core code manages RT
indexes for update tuple routing, which is ugly, but we don't have a
better idea right now.
Original report, analysis, and patch by Etsuro Fujita. Heavily
refactored by me. Then worked over some more by Amit Langote.
Discussion: http://postgr.es/m/5AD4882B.10002@lab.ntt.co.jp
2018-05-01 19:21:46 +02:00
|
|
|
delete from itrtest;
|
|
|
|
|
|
|
|
drop index loct1_idx;
|
|
|
|
|
|
|
|
-- Test that remote triggers work with insert tuple routing
|
|
|
|
create function br_insert_trigfunc() returns trigger as $$
|
|
|
|
begin
|
|
|
|
new.b := new.b || ' triggered !';
|
|
|
|
return new;
|
|
|
|
end
|
|
|
|
$$ language plpgsql;
|
|
|
|
create trigger loct1_br_insert_trigger before insert on loct1
|
|
|
|
for each row execute procedure br_insert_trigfunc();
|
|
|
|
create trigger loct2_br_insert_trigger before insert on loct2
|
|
|
|
for each row execute procedure br_insert_trigfunc();
|
|
|
|
|
|
|
|
-- The new values are concatenated with ' triggered !'
|
|
|
|
insert into itrtest values (1, 'foo') returning *;
|
|
|
|
insert into itrtest values (2, 'qux') returning *;
|
|
|
|
insert into itrtest values (1, 'test1'), (2, 'test2') returning *;
|
|
|
|
with result as (insert into itrtest values (1, 'test1'), (2, 'test2') returning *) select * from result;
|
|
|
|
|
|
|
|
drop trigger loct1_br_insert_trigger on loct1;
|
|
|
|
drop trigger loct2_br_insert_trigger on loct2;
|
|
|
|
|
2018-04-07 01:16:11 +02:00
|
|
|
drop table itrtest;
|
|
|
|
drop table loct1;
|
|
|
|
drop table loct2;
|
|
|
|
|
|
|
|
-- Test update tuple routing
|
|
|
|
create table utrtest (a int, b text) partition by list (a);
|
|
|
|
create table loct (a int check (a in (1)), b text);
|
|
|
|
create foreign table remp (a int check (a in (1)), b text) server loopback options (table_name 'loct');
|
|
|
|
create table locp (a int check (a in (2)), b text);
|
|
|
|
alter table utrtest attach partition remp for values in (1);
|
|
|
|
alter table utrtest attach partition locp for values in (2);
|
|
|
|
|
|
|
|
insert into utrtest values (1, 'foo');
|
|
|
|
insert into utrtest values (2, 'qux');
|
|
|
|
|
|
|
|
select tableoid::regclass, * FROM utrtest;
|
|
|
|
select tableoid::regclass, * FROM remp;
|
|
|
|
select tableoid::regclass, * FROM locp;
|
|
|
|
|
|
|
|
-- It's not allowed to move a row from a partition that is foreign to another
|
|
|
|
update utrtest set a = 2 where b = 'foo' returning *;
|
|
|
|
|
|
|
|
-- But the reverse is allowed
|
|
|
|
update utrtest set a = 1 where b = 'qux' returning *;
|
|
|
|
|
|
|
|
select tableoid::regclass, * FROM utrtest;
|
|
|
|
select tableoid::regclass, * FROM remp;
|
|
|
|
select tableoid::regclass, * FROM locp;
|
|
|
|
|
|
|
|
-- The executor should not let unexercised FDWs shut down
|
|
|
|
update utrtest set a = 1 where b = 'foo';
|
|
|
|
|
Fix interaction of foreign tuple routing with remote triggers.
Without these fixes, changes to the inserted tuple made by remote
triggers are ignored when building local RETURNING tuples.
In the core code, call ExecInitRoutingInfo at a later point from
within ExecInitPartitionInfo so that the FDW callback gets invoked
after the returning list has been built. But move CheckValidResultRel
out of ExecInitRoutingInfo so that it can happen at an earlier stage.
In postgres_fdw, refactor assorted deparsing functions to work with
the RTE rather than the PlannerInfo, which saves us having to
construct a fake PlannerInfo in cases where we don't have a real one.
Then, we can pass down a constructed RTE that yields the correct
deparse result when no real one exists. Unfortunately, this
necessitates a hack that understands how the core code manages RT
indexes for update tuple routing, which is ugly, but we don't have a
better idea right now.
Original report, analysis, and patch by Etsuro Fujita. Heavily
refactored by me. Then worked over some more by Amit Langote.
Discussion: http://postgr.es/m/5AD4882B.10002@lab.ntt.co.jp
2018-05-01 19:21:46 +02:00
|
|
|
-- Test that remote triggers work with update tuple routing
|
|
|
|
create trigger loct_br_insert_trigger before insert on loct
|
|
|
|
for each row execute procedure br_insert_trigfunc();
|
|
|
|
|
|
|
|
delete from utrtest;
|
|
|
|
insert into utrtest values (2, 'qux');
|
|
|
|
|
|
|
|
-- Check case where the foreign partition is a subplan target rel
|
|
|
|
explain (verbose, costs off)
|
|
|
|
update utrtest set a = 1 where a = 1 or a = 2 returning *;
|
|
|
|
-- The new values are concatenated with ' triggered !'
|
|
|
|
update utrtest set a = 1 where a = 1 or a = 2 returning *;
|
|
|
|
|
|
|
|
delete from utrtest;
|
|
|
|
insert into utrtest values (2, 'qux');
|
|
|
|
|
|
|
|
-- Check case where the foreign partition isn't a subplan target rel
|
|
|
|
explain (verbose, costs off)
|
|
|
|
update utrtest set a = 1 where a = 2 returning *;
|
|
|
|
-- The new values are concatenated with ' triggered !'
|
|
|
|
update utrtest set a = 1 where a = 2 returning *;
|
|
|
|
|
|
|
|
drop trigger loct_br_insert_trigger on loct;
|
|
|
|
|
2019-04-24 11:31:50 +02:00
|
|
|
-- We can move rows to a foreign partition that has been updated already,
|
|
|
|
-- but can't move rows to a foreign partition that hasn't been updated yet
|
|
|
|
|
|
|
|
delete from utrtest;
|
|
|
|
insert into utrtest values (1, 'foo');
|
|
|
|
insert into utrtest values (2, 'qux');
|
|
|
|
|
|
|
|
-- Test the former case:
|
|
|
|
-- with a direct modification plan
|
|
|
|
explain (verbose, costs off)
|
|
|
|
update utrtest set a = 1 returning *;
|
|
|
|
update utrtest set a = 1 returning *;
|
|
|
|
|
|
|
|
delete from utrtest;
|
|
|
|
insert into utrtest values (1, 'foo');
|
|
|
|
insert into utrtest values (2, 'qux');
|
|
|
|
|
|
|
|
-- with a non-direct modification plan
|
|
|
|
explain (verbose, costs off)
|
|
|
|
update utrtest set a = 1 from (values (1), (2)) s(x) where a = s.x returning *;
|
|
|
|
update utrtest set a = 1 from (values (1), (2)) s(x) where a = s.x returning *;
|
|
|
|
|
|
|
|
-- Change the definition of utrtest so that the foreign partition get updated
|
|
|
|
-- after the local partition
|
|
|
|
delete from utrtest;
|
|
|
|
alter table utrtest detach partition remp;
|
|
|
|
drop foreign table remp;
|
|
|
|
alter table loct drop constraint loct_a_check;
|
|
|
|
alter table loct add check (a in (3));
|
|
|
|
create foreign table remp (a int check (a in (3)), b text) server loopback options (table_name 'loct');
|
|
|
|
alter table utrtest attach partition remp for values in (3);
|
|
|
|
insert into utrtest values (2, 'qux');
|
|
|
|
insert into utrtest values (3, 'xyzzy');
|
|
|
|
|
|
|
|
-- Test the latter case:
|
|
|
|
-- with a direct modification plan
|
|
|
|
explain (verbose, costs off)
|
|
|
|
update utrtest set a = 3 returning *;
|
|
|
|
update utrtest set a = 3 returning *; -- ERROR
|
|
|
|
|
|
|
|
-- with a non-direct modification plan
|
|
|
|
explain (verbose, costs off)
|
|
|
|
update utrtest set a = 3 from (values (2), (3)) s(x) where a = s.x returning *;
|
|
|
|
update utrtest set a = 3 from (values (2), (3)) s(x) where a = s.x returning *; -- ERROR
|
|
|
|
|
2018-04-07 01:16:11 +02:00
|
|
|
drop table utrtest;
|
|
|
|
drop table loct;
|
|
|
|
|
|
|
|
-- Test copy tuple routing
|
|
|
|
create table ctrtest (a int, b text) partition by list (a);
|
|
|
|
create table loct1 (a int check (a in (1)), b text);
|
|
|
|
create foreign table remp1 (a int check (a in (1)), b text) server loopback options (table_name 'loct1');
|
|
|
|
create table loct2 (a int check (a in (2)), b text);
|
|
|
|
create foreign table remp2 (b text, a int check (a in (2))) server loopback options (table_name 'loct2');
|
|
|
|
alter table ctrtest attach partition remp1 for values in (1);
|
|
|
|
alter table ctrtest attach partition remp2 for values in (2);
|
|
|
|
|
|
|
|
copy ctrtest from stdin;
|
|
|
|
1 foo
|
|
|
|
2 qux
|
|
|
|
\.
|
|
|
|
|
|
|
|
select tableoid::regclass, * FROM ctrtest;
|
|
|
|
select tableoid::regclass, * FROM remp1;
|
|
|
|
select tableoid::regclass, * FROM remp2;
|
|
|
|
|
|
|
|
-- Copying into foreign partitions directly should work as well
|
|
|
|
copy remp1 from stdin;
|
|
|
|
1 bar
|
|
|
|
\.
|
|
|
|
|
|
|
|
select tableoid::regclass, * FROM remp1;
|
|
|
|
|
Allow batch insertion during COPY into a foreign table.
Commit 3d956d956 allowed the COPY, but it's done by inserting individual
rows to the foreign table, so it can be inefficient due to the overhead
caused by each round-trip to the foreign server. To improve performance
of the COPY in such a case, this patch allows batch insertion, by
extending the multi-insert machinery in CopyFrom() to the foreign-table
case so that we insert multiple rows to the foreign table at once using
the FDW callback routine added by commit b663a4136. This patch also
allows this for postgres_fdw. It is enabled by the "batch_size" option
added by commit b663a4136, which is disabled by default.
When doing batch insertion, we update progress of the COPY command after
performing the FDW callback routine, to count rows not suppressed by the
FDW as well as a BEFORE ROW INSERT trigger. For consistency, this patch
changes the timing of updating it for plain tables: previously, we
updated it immediately after adding each row to the multi-insert buffer,
but we do so only after writing the rows stored in the buffer out to the
table using table_multi_insert(), which I think would be consistent even
with non-batching mode, because in that mode we update it after writing
each row out to the table using table_tuple_insert().
Andrey Lepikhov, heavily revised by me, with review from Ian Barwick,
Andrey Lepikhov, and Zhihong Yu.
Discussion: https://postgr.es/m/bc489202-9855-7550-d64c-ad2d83c24867%40postgrespro.ru
2022-10-13 11:45:00 +02:00
|
|
|
delete from ctrtest;
|
|
|
|
|
|
|
|
-- Test copy tuple routing with the batch_size option enabled
|
|
|
|
alter server loopback options (add batch_size '2');
|
|
|
|
|
|
|
|
copy ctrtest from stdin;
|
|
|
|
1 foo
|
|
|
|
1 bar
|
|
|
|
2 baz
|
|
|
|
2 qux
|
|
|
|
1 test1
|
|
|
|
2 test2
|
|
|
|
\.
|
|
|
|
|
|
|
|
select tableoid::regclass, * FROM ctrtest;
|
|
|
|
select tableoid::regclass, * FROM remp1;
|
|
|
|
select tableoid::regclass, * FROM remp2;
|
|
|
|
|
|
|
|
delete from ctrtest;
|
|
|
|
|
|
|
|
alter server loopback options (drop batch_size);
|
|
|
|
|
2018-04-07 01:16:11 +02:00
|
|
|
drop table ctrtest;
|
|
|
|
drop table loct1;
|
|
|
|
drop table loct2;
|
|
|
|
|
|
|
|
-- ===================================================================
|
|
|
|
-- test COPY FROM
|
|
|
|
-- ===================================================================
|
|
|
|
|
|
|
|
create table loc2 (f1 int, f2 text);
|
|
|
|
alter table loc2 set (autovacuum_enabled = 'false');
|
|
|
|
create foreign table rem2 (f1 int, f2 text) server loopback options(table_name 'loc2');
|
|
|
|
|
|
|
|
-- Test basic functionality
|
|
|
|
copy rem2 from stdin;
|
|
|
|
1 foo
|
|
|
|
2 bar
|
|
|
|
\.
|
|
|
|
select * from rem2;
|
|
|
|
|
|
|
|
delete from rem2;
|
|
|
|
|
|
|
|
-- Test check constraints
|
|
|
|
alter table loc2 add constraint loc2_f1positive check (f1 >= 0);
|
|
|
|
alter foreign table rem2 add constraint rem2_f1positive check (f1 >= 0);
|
|
|
|
|
|
|
|
-- check constraint is enforced on the remote side, not locally
|
|
|
|
copy rem2 from stdin;
|
|
|
|
1 foo
|
|
|
|
2 bar
|
|
|
|
\.
|
|
|
|
copy rem2 from stdin; -- ERROR
|
|
|
|
-1 xyzzy
|
|
|
|
\.
|
|
|
|
select * from rem2;
|
|
|
|
|
|
|
|
alter foreign table rem2 drop constraint rem2_f1positive;
|
|
|
|
alter table loc2 drop constraint loc2_f1positive;
|
|
|
|
|
|
|
|
delete from rem2;
|
|
|
|
|
|
|
|
-- Test local triggers
|
|
|
|
create trigger trig_stmt_before before insert on rem2
|
|
|
|
for each statement execute procedure trigger_func();
|
|
|
|
create trigger trig_stmt_after after insert on rem2
|
|
|
|
for each statement execute procedure trigger_func();
|
|
|
|
create trigger trig_row_before before insert on rem2
|
|
|
|
for each row execute procedure trigger_data(23,'skidoo');
|
|
|
|
create trigger trig_row_after after insert on rem2
|
|
|
|
for each row execute procedure trigger_data(23,'skidoo');
|
|
|
|
|
|
|
|
copy rem2 from stdin;
|
|
|
|
1 foo
|
|
|
|
2 bar
|
|
|
|
\.
|
|
|
|
select * from rem2;
|
|
|
|
|
|
|
|
drop trigger trig_row_before on rem2;
|
|
|
|
drop trigger trig_row_after on rem2;
|
|
|
|
drop trigger trig_stmt_before on rem2;
|
|
|
|
drop trigger trig_stmt_after on rem2;
|
|
|
|
|
|
|
|
delete from rem2;
|
|
|
|
|
|
|
|
create trigger trig_row_before_insert before insert on rem2
|
|
|
|
for each row execute procedure trig_row_before_insupdate();
|
|
|
|
|
|
|
|
-- The new values are concatenated with ' triggered !'
|
|
|
|
copy rem2 from stdin;
|
|
|
|
1 foo
|
|
|
|
2 bar
|
|
|
|
\.
|
|
|
|
select * from rem2;
|
|
|
|
|
|
|
|
drop trigger trig_row_before_insert on rem2;
|
|
|
|
|
|
|
|
delete from rem2;
|
|
|
|
|
|
|
|
create trigger trig_null before insert on rem2
|
|
|
|
for each row execute procedure trig_null();
|
|
|
|
|
|
|
|
-- Nothing happens
|
|
|
|
copy rem2 from stdin;
|
|
|
|
1 foo
|
|
|
|
2 bar
|
|
|
|
\.
|
|
|
|
select * from rem2;
|
|
|
|
|
|
|
|
drop trigger trig_null on rem2;
|
|
|
|
|
|
|
|
delete from rem2;
|
|
|
|
|
|
|
|
-- Test remote triggers
|
|
|
|
create trigger trig_row_before_insert before insert on loc2
|
|
|
|
for each row execute procedure trig_row_before_insupdate();
|
|
|
|
|
|
|
|
-- The new values are concatenated with ' triggered !'
|
|
|
|
copy rem2 from stdin;
|
|
|
|
1 foo
|
|
|
|
2 bar
|
|
|
|
\.
|
|
|
|
select * from rem2;
|
|
|
|
|
|
|
|
drop trigger trig_row_before_insert on loc2;
|
|
|
|
|
|
|
|
delete from rem2;
|
|
|
|
|
|
|
|
create trigger trig_null before insert on loc2
|
|
|
|
for each row execute procedure trig_null();
|
|
|
|
|
|
|
|
-- Nothing happens
|
|
|
|
copy rem2 from stdin;
|
|
|
|
1 foo
|
|
|
|
2 bar
|
|
|
|
\.
|
|
|
|
select * from rem2;
|
|
|
|
|
|
|
|
drop trigger trig_null on loc2;
|
|
|
|
|
|
|
|
delete from rem2;
|
|
|
|
|
|
|
|
-- Test a combination of local and remote triggers
|
|
|
|
create trigger rem2_trig_row_before before insert on rem2
|
|
|
|
for each row execute procedure trigger_data(23,'skidoo');
|
|
|
|
create trigger rem2_trig_row_after after insert on rem2
|
|
|
|
for each row execute procedure trigger_data(23,'skidoo');
|
|
|
|
create trigger loc2_trig_row_before_insert before insert on loc2
|
|
|
|
for each row execute procedure trig_row_before_insupdate();
|
|
|
|
|
|
|
|
copy rem2 from stdin;
|
|
|
|
1 foo
|
|
|
|
2 bar
|
|
|
|
\.
|
|
|
|
select * from rem2;
|
|
|
|
|
|
|
|
drop trigger rem2_trig_row_before on rem2;
|
|
|
|
drop trigger rem2_trig_row_after on rem2;
|
|
|
|
drop trigger loc2_trig_row_before_insert on loc2;
|
|
|
|
|
|
|
|
delete from rem2;
|
|
|
|
|
2018-12-23 08:42:22 +01:00
|
|
|
-- test COPY FROM with foreign table created in the same transaction
|
|
|
|
create table loc3 (f1 int, f2 text);
|
|
|
|
begin;
|
|
|
|
create foreign table rem3 (f1 int, f2 text)
|
|
|
|
server loopback options(table_name 'loc3');
|
|
|
|
copy rem3 from stdin;
|
|
|
|
1 foo
|
|
|
|
2 bar
|
|
|
|
\.
|
|
|
|
commit;
|
|
|
|
select * from rem3;
|
|
|
|
drop foreign table rem3;
|
|
|
|
drop table loc3;
|
|
|
|
|
Allow batch insertion during COPY into a foreign table.
Commit 3d956d956 allowed the COPY, but it's done by inserting individual
rows to the foreign table, so it can be inefficient due to the overhead
caused by each round-trip to the foreign server. To improve performance
of the COPY in such a case, this patch allows batch insertion, by
extending the multi-insert machinery in CopyFrom() to the foreign-table
case so that we insert multiple rows to the foreign table at once using
the FDW callback routine added by commit b663a4136. This patch also
allows this for postgres_fdw. It is enabled by the "batch_size" option
added by commit b663a4136, which is disabled by default.
When doing batch insertion, we update progress of the COPY command after
performing the FDW callback routine, to count rows not suppressed by the
FDW as well as a BEFORE ROW INSERT trigger. For consistency, this patch
changes the timing of updating it for plain tables: previously, we
updated it immediately after adding each row to the multi-insert buffer,
but we do so only after writing the rows stored in the buffer out to the
table using table_multi_insert(), which I think would be consistent even
with non-batching mode, because in that mode we update it after writing
each row out to the table using table_tuple_insert().
Andrey Lepikhov, heavily revised by me, with review from Ian Barwick,
Andrey Lepikhov, and Zhihong Yu.
Discussion: https://postgr.es/m/bc489202-9855-7550-d64c-ad2d83c24867%40postgrespro.ru
2022-10-13 11:45:00 +02:00
|
|
|
-- Test COPY FROM with the batch_size option enabled
|
|
|
|
alter server loopback options (add batch_size '2');
|
|
|
|
|
|
|
|
-- Test basic functionality
|
|
|
|
copy rem2 from stdin;
|
|
|
|
1 foo
|
|
|
|
2 bar
|
|
|
|
3 baz
|
|
|
|
\.
|
|
|
|
select * from rem2;
|
|
|
|
|
|
|
|
delete from rem2;
|
|
|
|
|
|
|
|
-- Test check constraints
|
|
|
|
alter table loc2 add constraint loc2_f1positive check (f1 >= 0);
|
|
|
|
alter foreign table rem2 add constraint rem2_f1positive check (f1 >= 0);
|
|
|
|
|
|
|
|
-- check constraint is enforced on the remote side, not locally
|
|
|
|
copy rem2 from stdin;
|
|
|
|
1 foo
|
|
|
|
2 bar
|
|
|
|
3 baz
|
|
|
|
\.
|
|
|
|
copy rem2 from stdin; -- ERROR
|
|
|
|
-1 xyzzy
|
|
|
|
\.
|
|
|
|
select * from rem2;
|
|
|
|
|
|
|
|
alter foreign table rem2 drop constraint rem2_f1positive;
|
|
|
|
alter table loc2 drop constraint loc2_f1positive;
|
|
|
|
|
|
|
|
delete from rem2;
|
|
|
|
|
|
|
|
-- Test remote triggers
|
|
|
|
create trigger trig_row_before_insert before insert on loc2
|
|
|
|
for each row execute procedure trig_row_before_insupdate();
|
|
|
|
|
|
|
|
-- The new values are concatenated with ' triggered !'
|
|
|
|
copy rem2 from stdin;
|
|
|
|
1 foo
|
|
|
|
2 bar
|
|
|
|
3 baz
|
|
|
|
\.
|
|
|
|
select * from rem2;
|
|
|
|
|
|
|
|
drop trigger trig_row_before_insert on loc2;
|
|
|
|
|
|
|
|
delete from rem2;
|
|
|
|
|
|
|
|
create trigger trig_null before insert on loc2
|
|
|
|
for each row execute procedure trig_null();
|
|
|
|
|
|
|
|
-- Nothing happens
|
|
|
|
copy rem2 from stdin;
|
|
|
|
1 foo
|
|
|
|
2 bar
|
|
|
|
3 baz
|
|
|
|
\.
|
|
|
|
select * from rem2;
|
|
|
|
|
|
|
|
drop trigger trig_null on loc2;
|
|
|
|
|
|
|
|
delete from rem2;
|
|
|
|
|
|
|
|
-- Check with zero-column foreign table; batch insert will be disabled
|
|
|
|
alter table loc2 drop column f1;
|
|
|
|
alter table loc2 drop column f2;
|
|
|
|
alter table rem2 drop column f1;
|
|
|
|
alter table rem2 drop column f2;
|
|
|
|
copy rem2 from stdin;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\.
|
|
|
|
select * from rem2;
|
|
|
|
|
|
|
|
delete from rem2;
|
|
|
|
|
|
|
|
alter server loopback options (drop batch_size);
|
|
|
|
|
Allow TRUNCATE command to truncate foreign tables.
This commit introduces new foreign data wrapper API for TRUNCATE.
It extends TRUNCATE command so that it accepts foreign tables as
the targets to truncate and invokes that API. Also it extends postgres_fdw
so that it can issue TRUNCATE command to foreign servers, by adding
new routine for that TRUNCATE API.
The information about options specified in TRUNCATE command, e.g.,
ONLY, CACADE, etc is passed to FDW via API. The list of foreign tables to
truncate is also passed to FDW. FDW truncates the foreign data sources
that the passed foreign tables specify, based on those information.
For example, postgres_fdw constructs TRUNCATE command using them
and issues it to the foreign server.
For performance, TRUNCATE command invokes the FDW routine for
TRUNCATE once per foreign server that foreign tables to truncate belong to.
Author: Kazutaka Onishi, Kohei KaiGai, slightly modified by Fujii Masao
Reviewed-by: Bharath Rupireddy, Michael Paquier, Zhihong Yu, Alvaro Herrera, Stephen Frost, Ashutosh Bapat, Amit Langote, Daniel Gustafsson, Ibrar Ahmed, Fujii Masao
Discussion: https://postgr.es/m/CAOP8fzb_gkReLput7OvOK+8NHgw-RKqNv59vem7=524krQTcWA@mail.gmail.com
Discussion: https://postgr.es/m/CAJuF6cMWDDqU-vn_knZgma+2GMaout68YUgn1uyDnexRhqqM5Q@mail.gmail.com
2021-04-08 13:56:08 +02:00
|
|
|
-- ===================================================================
|
|
|
|
-- test for TRUNCATE
|
|
|
|
-- ===================================================================
|
|
|
|
CREATE TABLE tru_rtable0 (id int primary key);
|
|
|
|
CREATE FOREIGN TABLE tru_ftable (id int)
|
|
|
|
SERVER loopback OPTIONS (table_name 'tru_rtable0');
|
|
|
|
INSERT INTO tru_rtable0 (SELECT x FROM generate_series(1,10) x);
|
|
|
|
|
|
|
|
CREATE TABLE tru_ptable (id int) PARTITION BY HASH(id);
|
|
|
|
CREATE TABLE tru_ptable__p0 PARTITION OF tru_ptable
|
|
|
|
FOR VALUES WITH (MODULUS 2, REMAINDER 0);
|
2021-04-27 07:41:27 +02:00
|
|
|
CREATE TABLE tru_rtable1 (id int primary key);
|
Allow TRUNCATE command to truncate foreign tables.
This commit introduces new foreign data wrapper API for TRUNCATE.
It extends TRUNCATE command so that it accepts foreign tables as
the targets to truncate and invokes that API. Also it extends postgres_fdw
so that it can issue TRUNCATE command to foreign servers, by adding
new routine for that TRUNCATE API.
The information about options specified in TRUNCATE command, e.g.,
ONLY, CACADE, etc is passed to FDW via API. The list of foreign tables to
truncate is also passed to FDW. FDW truncates the foreign data sources
that the passed foreign tables specify, based on those information.
For example, postgres_fdw constructs TRUNCATE command using them
and issues it to the foreign server.
For performance, TRUNCATE command invokes the FDW routine for
TRUNCATE once per foreign server that foreign tables to truncate belong to.
Author: Kazutaka Onishi, Kohei KaiGai, slightly modified by Fujii Masao
Reviewed-by: Bharath Rupireddy, Michael Paquier, Zhihong Yu, Alvaro Herrera, Stephen Frost, Ashutosh Bapat, Amit Langote, Daniel Gustafsson, Ibrar Ahmed, Fujii Masao
Discussion: https://postgr.es/m/CAOP8fzb_gkReLput7OvOK+8NHgw-RKqNv59vem7=524krQTcWA@mail.gmail.com
Discussion: https://postgr.es/m/CAJuF6cMWDDqU-vn_knZgma+2GMaout68YUgn1uyDnexRhqqM5Q@mail.gmail.com
2021-04-08 13:56:08 +02:00
|
|
|
CREATE FOREIGN TABLE tru_ftable__p1 PARTITION OF tru_ptable
|
|
|
|
FOR VALUES WITH (MODULUS 2, REMAINDER 1)
|
|
|
|
SERVER loopback OPTIONS (table_name 'tru_rtable1');
|
|
|
|
INSERT INTO tru_ptable (SELECT x FROM generate_series(11,20) x);
|
|
|
|
|
|
|
|
CREATE TABLE tru_pk_table(id int primary key);
|
|
|
|
CREATE TABLE tru_fk_table(fkey int references tru_pk_table(id));
|
|
|
|
INSERT INTO tru_pk_table (SELECT x FROM generate_series(1,10) x);
|
|
|
|
INSERT INTO tru_fk_table (SELECT x % 10 + 1 FROM generate_series(5,25) x);
|
|
|
|
CREATE FOREIGN TABLE tru_pk_ftable (id int)
|
|
|
|
SERVER loopback OPTIONS (table_name 'tru_pk_table');
|
|
|
|
|
|
|
|
CREATE TABLE tru_rtable_parent (id int);
|
|
|
|
CREATE TABLE tru_rtable_child (id int);
|
|
|
|
CREATE FOREIGN TABLE tru_ftable_parent (id int)
|
|
|
|
SERVER loopback OPTIONS (table_name 'tru_rtable_parent');
|
|
|
|
CREATE FOREIGN TABLE tru_ftable_child () INHERITS (tru_ftable_parent)
|
|
|
|
SERVER loopback OPTIONS (table_name 'tru_rtable_child');
|
|
|
|
INSERT INTO tru_rtable_parent (SELECT x FROM generate_series(1,8) x);
|
|
|
|
INSERT INTO tru_rtable_child (SELECT x FROM generate_series(10, 18) x);
|
|
|
|
|
|
|
|
-- normal truncate
|
|
|
|
SELECT sum(id) FROM tru_ftable; -- 55
|
|
|
|
TRUNCATE tru_ftable;
|
|
|
|
SELECT count(*) FROM tru_rtable0; -- 0
|
|
|
|
SELECT count(*) FROM tru_ftable; -- 0
|
|
|
|
|
|
|
|
-- 'truncatable' option
|
|
|
|
ALTER SERVER loopback OPTIONS (ADD truncatable 'false');
|
|
|
|
TRUNCATE tru_ftable; -- error
|
|
|
|
ALTER FOREIGN TABLE tru_ftable OPTIONS (ADD truncatable 'true');
|
|
|
|
TRUNCATE tru_ftable; -- accepted
|
|
|
|
ALTER FOREIGN TABLE tru_ftable OPTIONS (SET truncatable 'false');
|
|
|
|
TRUNCATE tru_ftable; -- error
|
|
|
|
ALTER SERVER loopback OPTIONS (DROP truncatable);
|
|
|
|
ALTER FOREIGN TABLE tru_ftable OPTIONS (SET truncatable 'false');
|
|
|
|
TRUNCATE tru_ftable; -- error
|
|
|
|
ALTER FOREIGN TABLE tru_ftable OPTIONS (SET truncatable 'true');
|
|
|
|
TRUNCATE tru_ftable; -- accepted
|
|
|
|
|
|
|
|
-- partitioned table with both local and foreign tables as partitions
|
|
|
|
SELECT sum(id) FROM tru_ptable; -- 155
|
|
|
|
TRUNCATE tru_ptable;
|
|
|
|
SELECT count(*) FROM tru_ptable; -- 0
|
|
|
|
SELECT count(*) FROM tru_ptable__p0; -- 0
|
|
|
|
SELECT count(*) FROM tru_ftable__p1; -- 0
|
|
|
|
SELECT count(*) FROM tru_rtable1; -- 0
|
|
|
|
|
|
|
|
-- 'CASCADE' option
|
|
|
|
SELECT sum(id) FROM tru_pk_ftable; -- 55
|
|
|
|
TRUNCATE tru_pk_ftable; -- failed by FK reference
|
|
|
|
TRUNCATE tru_pk_ftable CASCADE;
|
|
|
|
SELECT count(*) FROM tru_pk_ftable; -- 0
|
|
|
|
SELECT count(*) FROM tru_fk_table; -- also truncated,0
|
|
|
|
|
|
|
|
-- truncate two tables at a command
|
|
|
|
INSERT INTO tru_ftable (SELECT x FROM generate_series(1,8) x);
|
|
|
|
INSERT INTO tru_pk_ftable (SELECT x FROM generate_series(3,10) x);
|
|
|
|
SELECT count(*) from tru_ftable; -- 8
|
|
|
|
SELECT count(*) from tru_pk_ftable; -- 8
|
|
|
|
TRUNCATE tru_ftable, tru_pk_ftable CASCADE;
|
|
|
|
SELECT count(*) from tru_ftable; -- 0
|
|
|
|
SELECT count(*) from tru_pk_ftable; -- 0
|
|
|
|
|
|
|
|
-- truncate with ONLY clause
|
2021-04-27 07:41:27 +02:00
|
|
|
-- Since ONLY is specified, the table tru_ftable_child that inherits
|
|
|
|
-- tru_ftable_parent locally is not truncated.
|
Allow TRUNCATE command to truncate foreign tables.
This commit introduces new foreign data wrapper API for TRUNCATE.
It extends TRUNCATE command so that it accepts foreign tables as
the targets to truncate and invokes that API. Also it extends postgres_fdw
so that it can issue TRUNCATE command to foreign servers, by adding
new routine for that TRUNCATE API.
The information about options specified in TRUNCATE command, e.g.,
ONLY, CACADE, etc is passed to FDW via API. The list of foreign tables to
truncate is also passed to FDW. FDW truncates the foreign data sources
that the passed foreign tables specify, based on those information.
For example, postgres_fdw constructs TRUNCATE command using them
and issues it to the foreign server.
For performance, TRUNCATE command invokes the FDW routine for
TRUNCATE once per foreign server that foreign tables to truncate belong to.
Author: Kazutaka Onishi, Kohei KaiGai, slightly modified by Fujii Masao
Reviewed-by: Bharath Rupireddy, Michael Paquier, Zhihong Yu, Alvaro Herrera, Stephen Frost, Ashutosh Bapat, Amit Langote, Daniel Gustafsson, Ibrar Ahmed, Fujii Masao
Discussion: https://postgr.es/m/CAOP8fzb_gkReLput7OvOK+8NHgw-RKqNv59vem7=524krQTcWA@mail.gmail.com
Discussion: https://postgr.es/m/CAJuF6cMWDDqU-vn_knZgma+2GMaout68YUgn1uyDnexRhqqM5Q@mail.gmail.com
2021-04-08 13:56:08 +02:00
|
|
|
TRUNCATE ONLY tru_ftable_parent;
|
|
|
|
SELECT sum(id) FROM tru_ftable_parent; -- 126
|
|
|
|
TRUNCATE tru_ftable_parent;
|
|
|
|
SELECT count(*) FROM tru_ftable_parent; -- 0
|
|
|
|
|
|
|
|
-- in case when remote table has inherited children
|
|
|
|
CREATE TABLE tru_rtable0_child () INHERITS (tru_rtable0);
|
|
|
|
INSERT INTO tru_rtable0 (SELECT x FROM generate_series(5,9) x);
|
|
|
|
INSERT INTO tru_rtable0_child (SELECT x FROM generate_series(10,14) x);
|
|
|
|
SELECT sum(id) FROM tru_ftable; -- 95
|
|
|
|
|
2021-04-27 07:41:27 +02:00
|
|
|
-- Both parent and child tables in the foreign server are truncated
|
|
|
|
-- even though ONLY is specified because ONLY has no effect
|
|
|
|
-- when truncating a foreign table.
|
|
|
|
TRUNCATE ONLY tru_ftable;
|
|
|
|
SELECT count(*) FROM tru_ftable; -- 0
|
Allow TRUNCATE command to truncate foreign tables.
This commit introduces new foreign data wrapper API for TRUNCATE.
It extends TRUNCATE command so that it accepts foreign tables as
the targets to truncate and invokes that API. Also it extends postgres_fdw
so that it can issue TRUNCATE command to foreign servers, by adding
new routine for that TRUNCATE API.
The information about options specified in TRUNCATE command, e.g.,
ONLY, CACADE, etc is passed to FDW via API. The list of foreign tables to
truncate is also passed to FDW. FDW truncates the foreign data sources
that the passed foreign tables specify, based on those information.
For example, postgres_fdw constructs TRUNCATE command using them
and issues it to the foreign server.
For performance, TRUNCATE command invokes the FDW routine for
TRUNCATE once per foreign server that foreign tables to truncate belong to.
Author: Kazutaka Onishi, Kohei KaiGai, slightly modified by Fujii Masao
Reviewed-by: Bharath Rupireddy, Michael Paquier, Zhihong Yu, Alvaro Herrera, Stephen Frost, Ashutosh Bapat, Amit Langote, Daniel Gustafsson, Ibrar Ahmed, Fujii Masao
Discussion: https://postgr.es/m/CAOP8fzb_gkReLput7OvOK+8NHgw-RKqNv59vem7=524krQTcWA@mail.gmail.com
Discussion: https://postgr.es/m/CAJuF6cMWDDqU-vn_knZgma+2GMaout68YUgn1uyDnexRhqqM5Q@mail.gmail.com
2021-04-08 13:56:08 +02:00
|
|
|
|
|
|
|
INSERT INTO tru_rtable0 (SELECT x FROM generate_series(21,25) x);
|
2021-04-27 07:41:27 +02:00
|
|
|
INSERT INTO tru_rtable0_child (SELECT x FROM generate_series(26,30) x);
|
|
|
|
SELECT sum(id) FROM tru_ftable; -- 255
|
Allow TRUNCATE command to truncate foreign tables.
This commit introduces new foreign data wrapper API for TRUNCATE.
It extends TRUNCATE command so that it accepts foreign tables as
the targets to truncate and invokes that API. Also it extends postgres_fdw
so that it can issue TRUNCATE command to foreign servers, by adding
new routine for that TRUNCATE API.
The information about options specified in TRUNCATE command, e.g.,
ONLY, CACADE, etc is passed to FDW via API. The list of foreign tables to
truncate is also passed to FDW. FDW truncates the foreign data sources
that the passed foreign tables specify, based on those information.
For example, postgres_fdw constructs TRUNCATE command using them
and issues it to the foreign server.
For performance, TRUNCATE command invokes the FDW routine for
TRUNCATE once per foreign server that foreign tables to truncate belong to.
Author: Kazutaka Onishi, Kohei KaiGai, slightly modified by Fujii Masao
Reviewed-by: Bharath Rupireddy, Michael Paquier, Zhihong Yu, Alvaro Herrera, Stephen Frost, Ashutosh Bapat, Amit Langote, Daniel Gustafsson, Ibrar Ahmed, Fujii Masao
Discussion: https://postgr.es/m/CAOP8fzb_gkReLput7OvOK+8NHgw-RKqNv59vem7=524krQTcWA@mail.gmail.com
Discussion: https://postgr.es/m/CAJuF6cMWDDqU-vn_knZgma+2GMaout68YUgn1uyDnexRhqqM5Q@mail.gmail.com
2021-04-08 13:56:08 +02:00
|
|
|
TRUNCATE tru_ftable; -- truncate both of parent and child
|
2021-04-27 07:41:27 +02:00
|
|
|
SELECT count(*) FROM tru_ftable; -- 0
|
Allow TRUNCATE command to truncate foreign tables.
This commit introduces new foreign data wrapper API for TRUNCATE.
It extends TRUNCATE command so that it accepts foreign tables as
the targets to truncate and invokes that API. Also it extends postgres_fdw
so that it can issue TRUNCATE command to foreign servers, by adding
new routine for that TRUNCATE API.
The information about options specified in TRUNCATE command, e.g.,
ONLY, CACADE, etc is passed to FDW via API. The list of foreign tables to
truncate is also passed to FDW. FDW truncates the foreign data sources
that the passed foreign tables specify, based on those information.
For example, postgres_fdw constructs TRUNCATE command using them
and issues it to the foreign server.
For performance, TRUNCATE command invokes the FDW routine for
TRUNCATE once per foreign server that foreign tables to truncate belong to.
Author: Kazutaka Onishi, Kohei KaiGai, slightly modified by Fujii Masao
Reviewed-by: Bharath Rupireddy, Michael Paquier, Zhihong Yu, Alvaro Herrera, Stephen Frost, Ashutosh Bapat, Amit Langote, Daniel Gustafsson, Ibrar Ahmed, Fujii Masao
Discussion: https://postgr.es/m/CAOP8fzb_gkReLput7OvOK+8NHgw-RKqNv59vem7=524krQTcWA@mail.gmail.com
Discussion: https://postgr.es/m/CAJuF6cMWDDqU-vn_knZgma+2GMaout68YUgn1uyDnexRhqqM5Q@mail.gmail.com
2021-04-08 13:56:08 +02:00
|
|
|
|
|
|
|
-- cleanup
|
|
|
|
DROP FOREIGN TABLE tru_ftable_parent, tru_ftable_child, tru_pk_ftable,tru_ftable__p1,tru_ftable;
|
|
|
|
DROP TABLE tru_rtable0, tru_rtable1, tru_ptable, tru_ptable__p0, tru_pk_table, tru_fk_table,
|
|
|
|
tru_rtable_parent,tru_rtable_child, tru_rtable0_child;
|
|
|
|
|
2014-07-10 21:01:31 +02:00
|
|
|
-- ===================================================================
|
|
|
|
-- test IMPORT FOREIGN SCHEMA
|
|
|
|
-- ===================================================================
|
|
|
|
|
|
|
|
CREATE SCHEMA import_source;
|
|
|
|
CREATE TABLE import_source.t1 (c1 int, c2 varchar NOT NULL);
|
|
|
|
CREATE TABLE import_source.t2 (c1 int default 42, c2 varchar NULL, c3 text collate "POSIX");
|
|
|
|
CREATE TYPE typ1 AS (m1 int, m2 varchar);
|
|
|
|
CREATE TABLE import_source.t3 (c1 timestamptz default now(), c2 typ1);
|
|
|
|
CREATE TABLE import_source."x 4" (c1 float8, "C 2" text, c3 varchar(42));
|
|
|
|
CREATE TABLE import_source."x 5" (c1 float8);
|
|
|
|
ALTER TABLE import_source."x 5" DROP COLUMN c1;
|
2021-08-05 13:00:00 +02:00
|
|
|
CREATE TABLE import_source."x 6" (c1 int, c2 int generated always as (c1 * 2) stored);
|
2017-03-31 21:01:35 +02:00
|
|
|
CREATE TABLE import_source.t4 (c1 int) PARTITION BY RANGE (c1);
|
|
|
|
CREATE TABLE import_source.t4_part PARTITION OF import_source.t4
|
|
|
|
FOR VALUES FROM (1) TO (100);
|
2021-04-06 19:32:10 +02:00
|
|
|
CREATE TABLE import_source.t4_part2 PARTITION OF import_source.t4
|
|
|
|
FOR VALUES FROM (100) TO (200);
|
2014-07-10 21:01:31 +02:00
|
|
|
|
|
|
|
CREATE SCHEMA import_dest1;
|
|
|
|
IMPORT FOREIGN SCHEMA import_source FROM SERVER loopback INTO import_dest1;
|
2016-01-29 10:28:02 +01:00
|
|
|
\det+ import_dest1.*
|
2014-07-10 21:01:31 +02:00
|
|
|
\d import_dest1.*
|
|
|
|
|
|
|
|
-- Options
|
|
|
|
CREATE SCHEMA import_dest2;
|
|
|
|
IMPORT FOREIGN SCHEMA import_source FROM SERVER loopback INTO import_dest2
|
|
|
|
OPTIONS (import_default 'true');
|
2016-01-29 10:28:02 +01:00
|
|
|
\det+ import_dest2.*
|
2014-07-10 21:01:31 +02:00
|
|
|
\d import_dest2.*
|
|
|
|
CREATE SCHEMA import_dest3;
|
|
|
|
IMPORT FOREIGN SCHEMA import_source FROM SERVER loopback INTO import_dest3
|
2021-08-05 13:00:00 +02:00
|
|
|
OPTIONS (import_collate 'false', import_generated 'false', import_not_null 'false');
|
2016-01-29 10:28:02 +01:00
|
|
|
\det+ import_dest3.*
|
2014-07-10 21:01:31 +02:00
|
|
|
\d import_dest3.*
|
|
|
|
|
|
|
|
-- Check LIMIT TO and EXCEPT
|
|
|
|
CREATE SCHEMA import_dest4;
|
2021-04-06 19:32:10 +02:00
|
|
|
IMPORT FOREIGN SCHEMA import_source LIMIT TO (t1, nonesuch, t4_part)
|
2014-07-10 21:01:31 +02:00
|
|
|
FROM SERVER loopback INTO import_dest4;
|
2016-01-29 10:28:02 +01:00
|
|
|
\det+ import_dest4.*
|
2021-04-06 19:32:10 +02:00
|
|
|
IMPORT FOREIGN SCHEMA import_source EXCEPT (t1, "x 4", nonesuch, t4_part)
|
2014-07-10 21:01:31 +02:00
|
|
|
FROM SERVER loopback INTO import_dest4;
|
2016-01-29 10:28:02 +01:00
|
|
|
\det+ import_dest4.*
|
2014-07-10 21:01:31 +02:00
|
|
|
|
|
|
|
-- Assorted error cases
|
|
|
|
IMPORT FOREIGN SCHEMA import_source FROM SERVER loopback INTO import_dest4;
|
|
|
|
IMPORT FOREIGN SCHEMA nonesuch FROM SERVER loopback INTO import_dest4;
|
|
|
|
IMPORT FOREIGN SCHEMA nonesuch FROM SERVER loopback INTO notthere;
|
|
|
|
IMPORT FOREIGN SCHEMA nonesuch FROM SERVER nowhere INTO notthere;
|
|
|
|
|
|
|
|
-- Check case of a type present only on the remote server.
|
|
|
|
-- We can fake this by dropping the type locally in our transaction.
|
|
|
|
CREATE TYPE "Colors" AS ENUM ('red', 'green', 'blue');
|
|
|
|
CREATE TABLE import_source.t5 (c1 int, c2 text collate "C", "Col" "Colors");
|
|
|
|
|
|
|
|
CREATE SCHEMA import_dest5;
|
|
|
|
BEGIN;
|
|
|
|
DROP TYPE "Colors" CASCADE;
|
|
|
|
IMPORT FOREIGN SCHEMA import_source LIMIT TO (t5)
|
|
|
|
FROM SERVER loopback INTO import_dest5; -- ERROR
|
2016-02-03 15:01:59 +01:00
|
|
|
|
|
|
|
ROLLBACK;
|
|
|
|
|
|
|
|
BEGIN;
|
|
|
|
|
|
|
|
|
|
|
|
CREATE SERVER fetch101 FOREIGN DATA WRAPPER postgres_fdw OPTIONS( fetch_size '101' );
|
|
|
|
|
|
|
|
SELECT count(*)
|
|
|
|
FROM pg_foreign_server
|
|
|
|
WHERE srvname = 'fetch101'
|
|
|
|
AND srvoptions @> array['fetch_size=101'];
|
|
|
|
|
|
|
|
ALTER SERVER fetch101 OPTIONS( SET fetch_size '202' );
|
|
|
|
|
|
|
|
SELECT count(*)
|
|
|
|
FROM pg_foreign_server
|
|
|
|
WHERE srvname = 'fetch101'
|
|
|
|
AND srvoptions @> array['fetch_size=101'];
|
|
|
|
|
|
|
|
SELECT count(*)
|
|
|
|
FROM pg_foreign_server
|
|
|
|
WHERE srvname = 'fetch101'
|
|
|
|
AND srvoptions @> array['fetch_size=202'];
|
|
|
|
|
|
|
|
CREATE FOREIGN TABLE table30000 ( x int ) SERVER fetch101 OPTIONS ( fetch_size '30000' );
|
|
|
|
|
|
|
|
SELECT COUNT(*)
|
|
|
|
FROM pg_foreign_table
|
|
|
|
WHERE ftrelid = 'table30000'::regclass
|
|
|
|
AND ftoptions @> array['fetch_size=30000'];
|
|
|
|
|
|
|
|
ALTER FOREIGN TABLE table30000 OPTIONS ( SET fetch_size '60000');
|
|
|
|
|
|
|
|
SELECT COUNT(*)
|
|
|
|
FROM pg_foreign_table
|
|
|
|
WHERE ftrelid = 'table30000'::regclass
|
|
|
|
AND ftoptions @> array['fetch_size=30000'];
|
|
|
|
|
|
|
|
SELECT COUNT(*)
|
|
|
|
FROM pg_foreign_table
|
|
|
|
WHERE ftrelid = 'table30000'::regclass
|
|
|
|
AND ftoptions @> array['fetch_size=60000'];
|
|
|
|
|
2014-07-10 21:01:31 +02:00
|
|
|
ROLLBACK;
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
2017-10-06 17:11:10 +02:00
|
|
|
|
|
|
|
-- ===================================================================
|
2018-02-16 16:33:59 +01:00
|
|
|
-- test partitionwise joins
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
2017-10-06 17:11:10 +02:00
|
|
|
-- ===================================================================
|
2018-02-16 16:33:59 +01:00
|
|
|
SET enable_partitionwise_join=on;
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
2017-10-06 17:11:10 +02:00
|
|
|
|
|
|
|
CREATE TABLE fprt1 (a int, b int, c varchar) PARTITION BY RANGE(a);
|
|
|
|
CREATE TABLE fprt1_p1 (LIKE fprt1);
|
|
|
|
CREATE TABLE fprt1_p2 (LIKE fprt1);
|
2018-03-02 19:16:01 +01:00
|
|
|
ALTER TABLE fprt1_p1 SET (autovacuum_enabled = 'false');
|
|
|
|
ALTER TABLE fprt1_p2 SET (autovacuum_enabled = 'false');
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
2017-10-06 17:11:10 +02:00
|
|
|
INSERT INTO fprt1_p1 SELECT i, i, to_char(i/50, 'FM0000') FROM generate_series(0, 249, 2) i;
|
|
|
|
INSERT INTO fprt1_p2 SELECT i, i, to_char(i/50, 'FM0000') FROM generate_series(250, 499, 2) i;
|
|
|
|
CREATE FOREIGN TABLE ftprt1_p1 PARTITION OF fprt1 FOR VALUES FROM (0) TO (250)
|
|
|
|
SERVER loopback OPTIONS (table_name 'fprt1_p1', use_remote_estimate 'true');
|
|
|
|
CREATE FOREIGN TABLE ftprt1_p2 PARTITION OF fprt1 FOR VALUES FROM (250) TO (500)
|
|
|
|
SERVER loopback OPTIONS (TABLE_NAME 'fprt1_p2');
|
|
|
|
ANALYZE fprt1;
|
|
|
|
ANALYZE fprt1_p1;
|
|
|
|
ANALYZE fprt1_p2;
|
|
|
|
|
|
|
|
CREATE TABLE fprt2 (a int, b int, c varchar) PARTITION BY RANGE(b);
|
|
|
|
CREATE TABLE fprt2_p1 (LIKE fprt2);
|
|
|
|
CREATE TABLE fprt2_p2 (LIKE fprt2);
|
2018-03-02 19:16:01 +01:00
|
|
|
ALTER TABLE fprt2_p1 SET (autovacuum_enabled = 'false');
|
|
|
|
ALTER TABLE fprt2_p2 SET (autovacuum_enabled = 'false');
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
2017-10-06 17:11:10 +02:00
|
|
|
INSERT INTO fprt2_p1 SELECT i, i, to_char(i/50, 'FM0000') FROM generate_series(0, 249, 3) i;
|
|
|
|
INSERT INTO fprt2_p2 SELECT i, i, to_char(i/50, 'FM0000') FROM generate_series(250, 499, 3) i;
|
Disable support for partitionwise joins in problematic cases.
Commit f49842d, which added support for partitionwise joins, built the
child's tlist by applying adjust_appendrel_attrs() to the parent's. So in
the case where the parent's included a whole-row Var for the parent, the
child's contained a ConvertRowtypeExpr. To cope with that, that commit
added code to the planner, such as setrefs.c, but some code paths still
assumed that the tlist for a scan (or join) rel would only include Vars
and PlaceHolderVars, which was true before that commit, causing errors:
* When creating an explicit sort node for an input path for a mergejoin
path for a child join, prepare_sort_from_pathkeys() threw the 'could not
find pathkey item to sort' error.
* When deparsing a relation participating in a pushed down child join as a
subquery in contrib/postgres_fdw, get_relation_column_alias_ids() threw
the 'unexpected expression in subquery output' error.
* When performing set_plan_references() on a local join plan generated by
contrib/postgres_fdw for EvalPlanQual support for a pushed down child
join, fix_join_expr() threw the 'variable not found in subplan target
lists' error.
To fix these, two approaches have been proposed: one by Ashutosh Bapat and
one by me. While the former keeps building the child's tlist with a
ConvertRowtypeExpr, the latter builds it with a whole-row Var for the
child not to violate the planner assumption, and tries to fix it up later,
But both approaches need more work, so refuse to generate partitionwise
join paths when whole-row Vars are involved, instead. We don't need to
handle ConvertRowtypeExprs in the child's tlists for now, so this commit
also removes the changes to the planner.
Previously, partitionwise join computed attr_needed data for each child
separately, and built the child join's tlist using that data, which also
required an extra step for adding PlaceHolderVars to that tlist, but it
would be more efficient to build it from the parent join's tlist through
the adjust_appendrel_attrs() transformation. So this commit builds that
list that way, and simplifies build_joinrel_tlist() and placeholder.c as
well as part of set_append_rel_size() to basically what they were before
partitionwise join went in.
Back-patch to PG11 where partitionwise join was introduced.
Report by Rajkumar Raghuwanshi. Analysis by Ashutosh Bapat, who also
provided some of regression tests. Patch by me, reviewed by Robert Haas.
Discussion: https://postgr.es/m/CAKcux6ktu-8tefLWtQuuZBYFaZA83vUzuRd7c1YHC-yEWyYFpg@mail.gmail.com
2018-08-31 13:34:06 +02:00
|
|
|
CREATE FOREIGN TABLE ftprt2_p1 (b int, c varchar, a int)
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
2017-10-06 17:11:10 +02:00
|
|
|
SERVER loopback OPTIONS (table_name 'fprt2_p1', use_remote_estimate 'true');
|
Disable support for partitionwise joins in problematic cases.
Commit f49842d, which added support for partitionwise joins, built the
child's tlist by applying adjust_appendrel_attrs() to the parent's. So in
the case where the parent's included a whole-row Var for the parent, the
child's contained a ConvertRowtypeExpr. To cope with that, that commit
added code to the planner, such as setrefs.c, but some code paths still
assumed that the tlist for a scan (or join) rel would only include Vars
and PlaceHolderVars, which was true before that commit, causing errors:
* When creating an explicit sort node for an input path for a mergejoin
path for a child join, prepare_sort_from_pathkeys() threw the 'could not
find pathkey item to sort' error.
* When deparsing a relation participating in a pushed down child join as a
subquery in contrib/postgres_fdw, get_relation_column_alias_ids() threw
the 'unexpected expression in subquery output' error.
* When performing set_plan_references() on a local join plan generated by
contrib/postgres_fdw for EvalPlanQual support for a pushed down child
join, fix_join_expr() threw the 'variable not found in subplan target
lists' error.
To fix these, two approaches have been proposed: one by Ashutosh Bapat and
one by me. While the former keeps building the child's tlist with a
ConvertRowtypeExpr, the latter builds it with a whole-row Var for the
child not to violate the planner assumption, and tries to fix it up later,
But both approaches need more work, so refuse to generate partitionwise
join paths when whole-row Vars are involved, instead. We don't need to
handle ConvertRowtypeExprs in the child's tlists for now, so this commit
also removes the changes to the planner.
Previously, partitionwise join computed attr_needed data for each child
separately, and built the child join's tlist using that data, which also
required an extra step for adding PlaceHolderVars to that tlist, but it
would be more efficient to build it from the parent join's tlist through
the adjust_appendrel_attrs() transformation. So this commit builds that
list that way, and simplifies build_joinrel_tlist() and placeholder.c as
well as part of set_append_rel_size() to basically what they were before
partitionwise join went in.
Back-patch to PG11 where partitionwise join was introduced.
Report by Rajkumar Raghuwanshi. Analysis by Ashutosh Bapat, who also
provided some of regression tests. Patch by me, reviewed by Robert Haas.
Discussion: https://postgr.es/m/CAKcux6ktu-8tefLWtQuuZBYFaZA83vUzuRd7c1YHC-yEWyYFpg@mail.gmail.com
2018-08-31 13:34:06 +02:00
|
|
|
ALTER TABLE fprt2 ATTACH PARTITION ftprt2_p1 FOR VALUES FROM (0) TO (250);
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
2017-10-06 17:11:10 +02:00
|
|
|
CREATE FOREIGN TABLE ftprt2_p2 PARTITION OF fprt2 FOR VALUES FROM (250) TO (500)
|
|
|
|
SERVER loopback OPTIONS (table_name 'fprt2_p2', use_remote_estimate 'true');
|
|
|
|
ANALYZE fprt2;
|
|
|
|
ANALYZE fprt2_p1;
|
|
|
|
ANALYZE fprt2_p2;
|
|
|
|
|
|
|
|
-- inner join three tables
|
|
|
|
EXPLAIN (COSTS OFF)
|
|
|
|
SELECT t1.a,t2.b,t3.c FROM fprt1 t1 INNER JOIN fprt2 t2 ON (t1.a = t2.b) INNER JOIN fprt1 t3 ON (t2.b = t3.a) WHERE t1.a % 25 =0 ORDER BY 1,2,3;
|
|
|
|
SELECT t1.a,t2.b,t3.c FROM fprt1 t1 INNER JOIN fprt2 t2 ON (t1.a = t2.b) INNER JOIN fprt1 t3 ON (t2.b = t3.a) WHERE t1.a % 25 =0 ORDER BY 1,2,3;
|
|
|
|
|
Suppress Append and MergeAppend plan nodes that have a single child.
If there's only one child relation, the Append or MergeAppend isn't
doing anything useful, and can be elided. It does have a purpose
during planning though, which is to serve as a buffer between parent
and child Var numbering. Therefore we keep it all the way through
to setrefs.c, and get rid of it only after fixing references in the
plan level(s) above it. This works largely the same as setrefs.c's
ancient hack to get rid of no-op SubqueryScan nodes, and can even
share some code with that.
Note the change to make setrefs.c use apply_tlist_labeling rather than
ad-hoc code. This has the effect of propagating the child's resjunk
and ressortgroupref labels, which formerly weren't propagated when
removing a SubqueryScan. Doing that is demonstrably necessary for
the [Merge]Append cases, and seems harmless for SubqueryScan, if only
because trivial_subqueryscan is afraid to collapse cases where the
resjunk marking differs. (I suspect that restriction could now be
removed, though it's unclear that it'd make any new matches possible,
since the outer query can't have references to a child resjunk column.)
David Rowley, reviewed by Alvaro Herrera and Tomas Vondra
Discussion: https://postgr.es/m/CAKJS1f_7u8ATyJ1JGTMHFoKDvZdeF-iEBhs+sM_SXowOr9cArg@mail.gmail.com
2019-03-25 20:42:35 +01:00
|
|
|
-- left outer join + nullable clause
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
2017-10-06 17:11:10 +02:00
|
|
|
SELECT t1.a,t2.b,t2.c FROM fprt1 t1 LEFT JOIN (SELECT * FROM fprt2 WHERE a < 10) t2 ON (t1.a = t2.b and t1.b = t2.a) WHERE t1.a < 10 ORDER BY 1,2,3;
|
|
|
|
SELECT t1.a,t2.b,t2.c FROM fprt1 t1 LEFT JOIN (SELECT * FROM fprt2 WHERE a < 10) t2 ON (t1.a = t2.b and t1.b = t2.a) WHERE t1.a < 10 ORDER BY 1,2,3;
|
|
|
|
|
Disable support for partitionwise joins in problematic cases.
Commit f49842d, which added support for partitionwise joins, built the
child's tlist by applying adjust_appendrel_attrs() to the parent's. So in
the case where the parent's included a whole-row Var for the parent, the
child's contained a ConvertRowtypeExpr. To cope with that, that commit
added code to the planner, such as setrefs.c, but some code paths still
assumed that the tlist for a scan (or join) rel would only include Vars
and PlaceHolderVars, which was true before that commit, causing errors:
* When creating an explicit sort node for an input path for a mergejoin
path for a child join, prepare_sort_from_pathkeys() threw the 'could not
find pathkey item to sort' error.
* When deparsing a relation participating in a pushed down child join as a
subquery in contrib/postgres_fdw, get_relation_column_alias_ids() threw
the 'unexpected expression in subquery output' error.
* When performing set_plan_references() on a local join plan generated by
contrib/postgres_fdw for EvalPlanQual support for a pushed down child
join, fix_join_expr() threw the 'variable not found in subplan target
lists' error.
To fix these, two approaches have been proposed: one by Ashutosh Bapat and
one by me. While the former keeps building the child's tlist with a
ConvertRowtypeExpr, the latter builds it with a whole-row Var for the
child not to violate the planner assumption, and tries to fix it up later,
But both approaches need more work, so refuse to generate partitionwise
join paths when whole-row Vars are involved, instead. We don't need to
handle ConvertRowtypeExprs in the child's tlists for now, so this commit
also removes the changes to the planner.
Previously, partitionwise join computed attr_needed data for each child
separately, and built the child join's tlist using that data, which also
required an extra step for adding PlaceHolderVars to that tlist, but it
would be more efficient to build it from the parent join's tlist through
the adjust_appendrel_attrs() transformation. So this commit builds that
list that way, and simplifies build_joinrel_tlist() and placeholder.c as
well as part of set_append_rel_size() to basically what they were before
partitionwise join went in.
Back-patch to PG11 where partitionwise join was introduced.
Report by Rajkumar Raghuwanshi. Analysis by Ashutosh Bapat, who also
provided some of regression tests. Patch by me, reviewed by Robert Haas.
Discussion: https://postgr.es/m/CAKcux6ktu-8tefLWtQuuZBYFaZA83vUzuRd7c1YHC-yEWyYFpg@mail.gmail.com
2018-08-31 13:34:06 +02:00
|
|
|
-- with whole-row reference; partitionwise join does not apply
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
2017-10-06 17:11:10 +02:00
|
|
|
EXPLAIN (COSTS OFF)
|
Disable support for partitionwise joins in problematic cases.
Commit f49842d, which added support for partitionwise joins, built the
child's tlist by applying adjust_appendrel_attrs() to the parent's. So in
the case where the parent's included a whole-row Var for the parent, the
child's contained a ConvertRowtypeExpr. To cope with that, that commit
added code to the planner, such as setrefs.c, but some code paths still
assumed that the tlist for a scan (or join) rel would only include Vars
and PlaceHolderVars, which was true before that commit, causing errors:
* When creating an explicit sort node for an input path for a mergejoin
path for a child join, prepare_sort_from_pathkeys() threw the 'could not
find pathkey item to sort' error.
* When deparsing a relation participating in a pushed down child join as a
subquery in contrib/postgres_fdw, get_relation_column_alias_ids() threw
the 'unexpected expression in subquery output' error.
* When performing set_plan_references() on a local join plan generated by
contrib/postgres_fdw for EvalPlanQual support for a pushed down child
join, fix_join_expr() threw the 'variable not found in subplan target
lists' error.
To fix these, two approaches have been proposed: one by Ashutosh Bapat and
one by me. While the former keeps building the child's tlist with a
ConvertRowtypeExpr, the latter builds it with a whole-row Var for the
child not to violate the planner assumption, and tries to fix it up later,
But both approaches need more work, so refuse to generate partitionwise
join paths when whole-row Vars are involved, instead. We don't need to
handle ConvertRowtypeExprs in the child's tlists for now, so this commit
also removes the changes to the planner.
Previously, partitionwise join computed attr_needed data for each child
separately, and built the child join's tlist using that data, which also
required an extra step for adding PlaceHolderVars to that tlist, but it
would be more efficient to build it from the parent join's tlist through
the adjust_appendrel_attrs() transformation. So this commit builds that
list that way, and simplifies build_joinrel_tlist() and placeholder.c as
well as part of set_append_rel_size() to basically what they were before
partitionwise join went in.
Back-patch to PG11 where partitionwise join was introduced.
Report by Rajkumar Raghuwanshi. Analysis by Ashutosh Bapat, who also
provided some of regression tests. Patch by me, reviewed by Robert Haas.
Discussion: https://postgr.es/m/CAKcux6ktu-8tefLWtQuuZBYFaZA83vUzuRd7c1YHC-yEWyYFpg@mail.gmail.com
2018-08-31 13:34:06 +02:00
|
|
|
SELECT t1.wr, t2.wr FROM (SELECT t1 wr, a FROM fprt1 t1 WHERE t1.a % 25 = 0) t1 FULL JOIN (SELECT t2 wr, b FROM fprt2 t2 WHERE t2.b % 25 = 0) t2 ON (t1.a = t2.b) ORDER BY 1,2;
|
|
|
|
SELECT t1.wr, t2.wr FROM (SELECT t1 wr, a FROM fprt1 t1 WHERE t1.a % 25 = 0) t1 FULL JOIN (SELECT t2 wr, b FROM fprt2 t2 WHERE t2.b % 25 = 0) t2 ON (t1.a = t2.b) ORDER BY 1,2;
|
Basic partition-wise join functionality.
Instead of joining two partitioned tables in their entirety we can, if
it is an equi-join on the partition keys, join the matching partitions
individually. This involves teaching the planner about "other join"
rels, which are related to regular join rels in the same way that
other member rels are related to baserels. This can use significantly
more CPU time and memory than regular join planning, because there may
now be a set of "other" rels not only for every base relation but also
for every join relation. In most practical cases, this probably
shouldn't be a problem, because (1) it's probably unusual to join many
tables each with many partitions using the partition keys for all
joins and (2) if you do that scenario then you probably have a big
enough machine to handle the increased memory cost of planning and (3)
the resulting plan is highly likely to be better, so what you spend in
planning you'll make up on the execution side. All the same, for now,
turn this feature off by default.
Currently, we can only perform joins between two tables whose
partitioning schemes are absolutely identical. It would be nice to
cope with other scenarios, such as extra partitions on one side or the
other with no match on the other side, but that will have to wait for
a future patch.
Ashutosh Bapat, reviewed and tested by Rajkumar Raghuwanshi, Amit
Langote, Rafia Sabih, Thomas Munro, Dilip Kumar, Antonin Houska, Amit
Khandekar, and by me. A few final adjustments by me.
Discussion: http://postgr.es/m/CAFjFpRfQ8GrQvzp3jA2wnLqrHmaXna-urjm_UY9BqXj=EaDTSA@mail.gmail.com
Discussion: http://postgr.es/m/CAFjFpRcitjfrULr5jfuKWRPsGUX0LQ0k8-yG0Qw2+1LBGNpMdw@mail.gmail.com
2017-10-06 17:11:10 +02:00
|
|
|
|
|
|
|
-- join with lateral reference
|
|
|
|
EXPLAIN (COSTS OFF)
|
|
|
|
SELECT t1.a,t1.b FROM fprt1 t1, LATERAL (SELECT t2.a, t2.b FROM fprt2 t2 WHERE t1.a = t2.b AND t1.b = t2.a) q WHERE t1.a%25 = 0 ORDER BY 1,2;
|
|
|
|
SELECT t1.a,t1.b FROM fprt1 t1, LATERAL (SELECT t2.a, t2.b FROM fprt2 t2 WHERE t1.a = t2.b AND t1.b = t2.a) q WHERE t1.a%25 = 0 ORDER BY 1,2;
|
|
|
|
|
2018-08-09 09:41:28 +02:00
|
|
|
-- with PHVs, partitionwise join selected but no join pushdown
|
2018-02-22 16:03:14 +01:00
|
|
|
EXPLAIN (COSTS OFF)
|
|
|
|
SELECT t1.a, t1.phv, t2.b, t2.phv FROM (SELECT 't1_phv' phv, * FROM fprt1 WHERE a % 25 = 0) t1 FULL JOIN (SELECT 't2_phv' phv, * FROM fprt2 WHERE b % 25 = 0) t2 ON (t1.a = t2.b) ORDER BY t1.a, t2.b;
|
|
|
|
SELECT t1.a, t1.phv, t2.b, t2.phv FROM (SELECT 't1_phv' phv, * FROM fprt1 WHERE a % 25 = 0) t1 FULL JOIN (SELECT 't2_phv' phv, * FROM fprt2 WHERE b % 25 = 0) t2 ON (t1.a = t2.b) ORDER BY t1.a, t2.b;
|
|
|
|
|
Disable support for partitionwise joins in problematic cases.
Commit f49842d, which added support for partitionwise joins, built the
child's tlist by applying adjust_appendrel_attrs() to the parent's. So in
the case where the parent's included a whole-row Var for the parent, the
child's contained a ConvertRowtypeExpr. To cope with that, that commit
added code to the planner, such as setrefs.c, but some code paths still
assumed that the tlist for a scan (or join) rel would only include Vars
and PlaceHolderVars, which was true before that commit, causing errors:
* When creating an explicit sort node for an input path for a mergejoin
path for a child join, prepare_sort_from_pathkeys() threw the 'could not
find pathkey item to sort' error.
* When deparsing a relation participating in a pushed down child join as a
subquery in contrib/postgres_fdw, get_relation_column_alias_ids() threw
the 'unexpected expression in subquery output' error.
* When performing set_plan_references() on a local join plan generated by
contrib/postgres_fdw for EvalPlanQual support for a pushed down child
join, fix_join_expr() threw the 'variable not found in subplan target
lists' error.
To fix these, two approaches have been proposed: one by Ashutosh Bapat and
one by me. While the former keeps building the child's tlist with a
ConvertRowtypeExpr, the latter builds it with a whole-row Var for the
child not to violate the planner assumption, and tries to fix it up later,
But both approaches need more work, so refuse to generate partitionwise
join paths when whole-row Vars are involved, instead. We don't need to
handle ConvertRowtypeExprs in the child's tlists for now, so this commit
also removes the changes to the planner.
Previously, partitionwise join computed attr_needed data for each child
separately, and built the child join's tlist using that data, which also
required an extra step for adding PlaceHolderVars to that tlist, but it
would be more efficient to build it from the parent join's tlist through
the adjust_appendrel_attrs() transformation. So this commit builds that
list that way, and simplifies build_joinrel_tlist() and placeholder.c as
well as part of set_append_rel_size() to basically what they were before
partitionwise join went in.
Back-patch to PG11 where partitionwise join was introduced.
Report by Rajkumar Raghuwanshi. Analysis by Ashutosh Bapat, who also
provided some of regression tests. Patch by me, reviewed by Robert Haas.
Discussion: https://postgr.es/m/CAKcux6ktu-8tefLWtQuuZBYFaZA83vUzuRd7c1YHC-yEWyYFpg@mail.gmail.com
2018-08-31 13:34:06 +02:00
|
|
|
-- test FOR UPDATE; partitionwise join does not apply
|
|
|
|
EXPLAIN (COSTS OFF)
|
|
|
|
SELECT t1.a, t2.b FROM fprt1 t1 INNER JOIN fprt2 t2 ON (t1.a = t2.b) WHERE t1.a % 25 = 0 ORDER BY 1,2 FOR UPDATE OF t1;
|
|
|
|
SELECT t1.a, t2.b FROM fprt1 t1 INNER JOIN fprt2 t2 ON (t1.a = t2.b) WHERE t1.a % 25 = 0 ORDER BY 1,2 FOR UPDATE OF t1;
|
|
|
|
|
2018-02-16 16:33:59 +01:00
|
|
|
RESET enable_partitionwise_join;
|
2018-04-02 16:51:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
-- ===================================================================
|
|
|
|
-- test partitionwise aggregates
|
|
|
|
-- ===================================================================
|
|
|
|
|
|
|
|
CREATE TABLE pagg_tab (a int, b int, c text) PARTITION BY RANGE(a);
|
|
|
|
|
|
|
|
CREATE TABLE pagg_tab_p1 (LIKE pagg_tab);
|
|
|
|
CREATE TABLE pagg_tab_p2 (LIKE pagg_tab);
|
|
|
|
CREATE TABLE pagg_tab_p3 (LIKE pagg_tab);
|
|
|
|
|
|
|
|
INSERT INTO pagg_tab_p1 SELECT i % 30, i % 50, to_char(i/30, 'FM0000') FROM generate_series(1, 3000) i WHERE (i % 30) < 10;
|
|
|
|
INSERT INTO pagg_tab_p2 SELECT i % 30, i % 50, to_char(i/30, 'FM0000') FROM generate_series(1, 3000) i WHERE (i % 30) < 20 and (i % 30) >= 10;
|
|
|
|
INSERT INTO pagg_tab_p3 SELECT i % 30, i % 50, to_char(i/30, 'FM0000') FROM generate_series(1, 3000) i WHERE (i % 30) < 30 and (i % 30) >= 20;
|
|
|
|
|
|
|
|
-- Create foreign partitions
|
|
|
|
CREATE FOREIGN TABLE fpagg_tab_p1 PARTITION OF pagg_tab FOR VALUES FROM (0) TO (10) SERVER loopback OPTIONS (table_name 'pagg_tab_p1');
|
2021-03-31 07:06:39 +02:00
|
|
|
CREATE FOREIGN TABLE fpagg_tab_p2 PARTITION OF pagg_tab FOR VALUES FROM (10) TO (20) SERVER loopback OPTIONS (table_name 'pagg_tab_p2');
|
|
|
|
CREATE FOREIGN TABLE fpagg_tab_p3 PARTITION OF pagg_tab FOR VALUES FROM (20) TO (30) SERVER loopback OPTIONS (table_name 'pagg_tab_p3');
|
2018-04-02 16:51:50 +02:00
|
|
|
|
|
|
|
ANALYZE pagg_tab;
|
|
|
|
ANALYZE fpagg_tab_p1;
|
|
|
|
ANALYZE fpagg_tab_p2;
|
|
|
|
ANALYZE fpagg_tab_p3;
|
|
|
|
|
|
|
|
-- When GROUP BY clause matches with PARTITION KEY.
|
|
|
|
-- Plan with partitionwise aggregates is disabled
|
|
|
|
SET enable_partitionwise_aggregate TO false;
|
|
|
|
EXPLAIN (COSTS OFF)
|
|
|
|
SELECT a, sum(b), min(b), count(*) FROM pagg_tab GROUP BY a HAVING avg(b) < 22 ORDER BY 1;
|
|
|
|
|
|
|
|
-- Plan with partitionwise aggregates is enabled
|
|
|
|
SET enable_partitionwise_aggregate TO true;
|
|
|
|
EXPLAIN (COSTS OFF)
|
|
|
|
SELECT a, sum(b), min(b), count(*) FROM pagg_tab GROUP BY a HAVING avg(b) < 22 ORDER BY 1;
|
|
|
|
SELECT a, sum(b), min(b), count(*) FROM pagg_tab GROUP BY a HAVING avg(b) < 22 ORDER BY 1;
|
|
|
|
|
|
|
|
-- Check with whole-row reference
|
|
|
|
-- Should have all the columns in the target list for the given relation
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT a, count(t1) FROM pagg_tab t1 GROUP BY a HAVING avg(b) < 22 ORDER BY 1;
|
|
|
|
SELECT a, count(t1) FROM pagg_tab t1 GROUP BY a HAVING avg(b) < 22 ORDER BY 1;
|
|
|
|
|
|
|
|
-- When GROUP BY clause does not match with PARTITION KEY.
|
|
|
|
EXPLAIN (COSTS OFF)
|
|
|
|
SELECT b, avg(a), max(a), count(*) FROM pagg_tab GROUP BY b HAVING sum(a) < 700 ORDER BY 1;
|
|
|
|
|
2019-12-20 06:53:34 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- access rights and superuser
|
|
|
|
-- ===================================================================
|
|
|
|
|
|
|
|
-- Non-superuser cannot create a FDW without a password in the connstr
|
2019-12-20 21:45:37 +01:00
|
|
|
CREATE ROLE regress_nosuper NOSUPERUSER;
|
2019-12-20 06:53:34 +01:00
|
|
|
|
2019-12-20 21:45:37 +01:00
|
|
|
GRANT USAGE ON FOREIGN DATA WRAPPER postgres_fdw TO regress_nosuper;
|
2019-12-20 06:53:34 +01:00
|
|
|
|
2019-12-20 21:45:37 +01:00
|
|
|
SET ROLE regress_nosuper;
|
2019-12-20 06:53:34 +01:00
|
|
|
|
|
|
|
SHOW is_superuser;
|
|
|
|
|
|
|
|
-- This will be OK, we can create the FDW
|
|
|
|
DO $d$
|
|
|
|
BEGIN
|
|
|
|
EXECUTE $$CREATE SERVER loopback_nopw FOREIGN DATA WRAPPER postgres_fdw
|
|
|
|
OPTIONS (dbname '$$||current_database()||$$',
|
|
|
|
port '$$||current_setting('port')||$$'
|
|
|
|
)$$;
|
|
|
|
END;
|
|
|
|
$d$;
|
|
|
|
|
|
|
|
-- But creation of user mappings for non-superusers should fail
|
|
|
|
CREATE USER MAPPING FOR public SERVER loopback_nopw;
|
|
|
|
CREATE USER MAPPING FOR CURRENT_USER SERVER loopback_nopw;
|
|
|
|
|
2021-09-10 08:38:09 +02:00
|
|
|
CREATE FOREIGN TABLE pg_temp.ft1_nopw (
|
2019-12-20 06:53:34 +01:00
|
|
|
c1 int NOT NULL,
|
|
|
|
c2 int NOT NULL,
|
|
|
|
c3 text,
|
|
|
|
c4 timestamptz,
|
|
|
|
c5 timestamp,
|
|
|
|
c6 varchar(10),
|
|
|
|
c7 char(10) default 'ft1',
|
|
|
|
c8 user_enum
|
|
|
|
) SERVER loopback_nopw OPTIONS (schema_name 'public', table_name 'ft1');
|
|
|
|
|
2021-06-24 21:02:13 +02:00
|
|
|
SELECT 1 FROM ft1_nopw LIMIT 1;
|
2019-12-20 06:53:34 +01:00
|
|
|
|
|
|
|
-- If we add a password to the connstr it'll fail, because we don't allow passwords
|
|
|
|
-- in connstrs only in user mappings.
|
|
|
|
|
2022-09-16 15:57:34 +02:00
|
|
|
ALTER SERVER loopback_nopw OPTIONS (ADD password 'dummypw');
|
2019-12-20 06:53:34 +01:00
|
|
|
|
|
|
|
-- If we add a password for our user mapping instead, we should get a different
|
|
|
|
-- error because the password wasn't actually *used* when we run with trust auth.
|
|
|
|
--
|
|
|
|
-- This won't work with installcheck, but neither will most of the FDW checks.
|
|
|
|
|
|
|
|
ALTER USER MAPPING FOR CURRENT_USER SERVER loopback_nopw OPTIONS (ADD password 'dummypw');
|
|
|
|
|
2021-06-24 21:02:13 +02:00
|
|
|
SELECT 1 FROM ft1_nopw LIMIT 1;
|
2019-12-20 06:53:34 +01:00
|
|
|
|
|
|
|
-- Unpriv user cannot make the mapping passwordless
|
|
|
|
ALTER USER MAPPING FOR CURRENT_USER SERVER loopback_nopw OPTIONS (ADD password_required 'false');
|
|
|
|
|
2020-01-13 08:38:09 +01:00
|
|
|
|
2021-06-24 21:02:13 +02:00
|
|
|
SELECT 1 FROM ft1_nopw LIMIT 1;
|
2019-12-20 06:53:34 +01:00
|
|
|
|
|
|
|
RESET ROLE;
|
|
|
|
|
|
|
|
-- But the superuser can
|
2019-12-20 21:45:37 +01:00
|
|
|
ALTER USER MAPPING FOR regress_nosuper SERVER loopback_nopw OPTIONS (ADD password_required 'false');
|
2019-12-20 06:53:34 +01:00
|
|
|
|
2019-12-20 21:45:37 +01:00
|
|
|
SET ROLE regress_nosuper;
|
2019-12-20 06:53:34 +01:00
|
|
|
|
|
|
|
-- Should finally work now
|
2021-06-24 21:02:13 +02:00
|
|
|
SELECT 1 FROM ft1_nopw LIMIT 1;
|
2019-12-20 06:53:34 +01:00
|
|
|
|
2020-01-13 08:38:09 +01:00
|
|
|
-- unpriv user also cannot set sslcert / sslkey on the user mapping
|
|
|
|
-- first set password_required so we see the right error messages
|
|
|
|
ALTER USER MAPPING FOR CURRENT_USER SERVER loopback_nopw OPTIONS (SET password_required 'true');
|
|
|
|
ALTER USER MAPPING FOR CURRENT_USER SERVER loopback_nopw OPTIONS (ADD sslcert 'foo.crt');
|
|
|
|
ALTER USER MAPPING FOR CURRENT_USER SERVER loopback_nopw OPTIONS (ADD sslkey 'foo.key');
|
|
|
|
|
2019-12-20 06:53:34 +01:00
|
|
|
-- We're done with the role named after a specific user and need to check the
|
|
|
|
-- changes to the public mapping.
|
|
|
|
DROP USER MAPPING FOR CURRENT_USER SERVER loopback_nopw;
|
|
|
|
|
|
|
|
-- This will fail again as it'll resolve the user mapping for public, which
|
|
|
|
-- lacks password_required=false
|
2021-06-24 21:02:13 +02:00
|
|
|
SELECT 1 FROM ft1_nopw LIMIT 1;
|
2019-12-20 06:53:34 +01:00
|
|
|
|
|
|
|
RESET ROLE;
|
|
|
|
|
|
|
|
-- The user mapping for public is passwordless and lacks the password_required=false
|
|
|
|
-- mapping option, but will work because the current user is a superuser.
|
2021-06-24 21:02:13 +02:00
|
|
|
SELECT 1 FROM ft1_nopw LIMIT 1;
|
2018-04-02 16:51:50 +02:00
|
|
|
|
2019-12-20 21:45:37 +01:00
|
|
|
-- cleanup
|
|
|
|
DROP USER MAPPING FOR public SERVER loopback_nopw;
|
|
|
|
DROP OWNED BY regress_nosuper;
|
|
|
|
DROP ROLE regress_nosuper;
|
|
|
|
|
2018-04-02 16:51:50 +02:00
|
|
|
-- Clean-up
|
|
|
|
RESET enable_partitionwise_aggregate;
|
2019-11-13 05:30:14 +01:00
|
|
|
|
|
|
|
-- Two-phase transactions are not supported.
|
|
|
|
BEGIN;
|
|
|
|
SELECT count(*) FROM ft1;
|
|
|
|
-- error here
|
|
|
|
PREPARE TRANSACTION 'fdw_tpc';
|
|
|
|
ROLLBACK;
|
2020-10-06 03:31:09 +02:00
|
|
|
|
|
|
|
-- ===================================================================
|
|
|
|
-- reestablish new connection
|
|
|
|
-- ===================================================================
|
|
|
|
|
|
|
|
-- Change application_name of remote connection to special one
|
|
|
|
-- so that we can easily terminate the connection later.
|
|
|
|
ALTER SERVER loopback OPTIONS (application_name 'fdw_retry_check');
|
2021-05-04 19:36:26 +02:00
|
|
|
|
|
|
|
-- Make sure we have a remote connection.
|
2020-10-06 03:31:09 +02:00
|
|
|
SELECT 1 FROM ft1 LIMIT 1;
|
|
|
|
|
2021-04-14 07:23:53 +02:00
|
|
|
-- Terminate the remote connection and wait for the termination to complete.
|
Harden postgres_fdw tests against unexpected cache flushes.
postgres_fdw will close its remote session if an sinval cache reset
occurs, since it's possible that that means some FDW parameters
changed. We had two tests that were trying to ensure that the
session remains alive by setting debug_discard_caches = 0; but
that's not sufficient. Even though the tests seem stable enough
in the buildfarm, they flap a lot under CI.
In the first test, which is checking the ability to recover from
a lost connection, we can stabilize the results by just not
caring whether pg_terminate_backend() finds a victim backend.
If a reset did happen, there won't be a session to terminate
anymore, but the test can proceed anyway. (Arguably, we are
then not testing the unintentional-disconnect case, but as long
as that scenario is exercised in most runs I think it's fine;
testing the reset-driven case is of value too.)
In the second test, which is trying to verify the application_name
displayed in pg_stat_activity by a remote session, we had a race
condition in that the remote session might go away before we can
fetch its pg_stat_activity entry. We can close that race and make
the test more certainly test what it intends to by arranging things
so that the remote session itself fetches its pg_stat_activity entry
(based on PID rather than a somewhat-circular assumption about the
application name).
Both tests now demonstrably pass under debug_discard_caches = 1,
so we can remove that hack.
Back-patch into relevant back branches.
Discussion: https://postgr.es/m/20230226194340.u44bkfgyz64c67i6@awork3.anarazel.de
2023-02-27 22:29:51 +01:00
|
|
|
-- (If a cache flush happens, the remote connection might have already been
|
|
|
|
-- dropped; so code this step in a way that doesn't fail if no connection.)
|
|
|
|
DO $$ BEGIN
|
|
|
|
PERFORM pg_terminate_backend(pid, 180000) FROM pg_stat_activity
|
2021-04-14 07:23:53 +02:00
|
|
|
WHERE application_name = 'fdw_retry_check';
|
Harden postgres_fdw tests against unexpected cache flushes.
postgres_fdw will close its remote session if an sinval cache reset
occurs, since it's possible that that means some FDW parameters
changed. We had two tests that were trying to ensure that the
session remains alive by setting debug_discard_caches = 0; but
that's not sufficient. Even though the tests seem stable enough
in the buildfarm, they flap a lot under CI.
In the first test, which is checking the ability to recover from
a lost connection, we can stabilize the results by just not
caring whether pg_terminate_backend() finds a victim backend.
If a reset did happen, there won't be a session to terminate
anymore, but the test can proceed anyway. (Arguably, we are
then not testing the unintentional-disconnect case, but as long
as that scenario is exercised in most runs I think it's fine;
testing the reset-driven case is of value too.)
In the second test, which is trying to verify the application_name
displayed in pg_stat_activity by a remote session, we had a race
condition in that the remote session might go away before we can
fetch its pg_stat_activity entry. We can close that race and make
the test more certainly test what it intends to by arranging things
so that the remote session itself fetches its pg_stat_activity entry
(based on PID rather than a somewhat-circular assumption about the
application name).
Both tests now demonstrably pass under debug_discard_caches = 1,
so we can remove that hack.
Back-patch into relevant back branches.
Discussion: https://postgr.es/m/20230226194340.u44bkfgyz64c67i6@awork3.anarazel.de
2023-02-27 22:29:51 +01:00
|
|
|
END $$;
|
2020-10-06 03:31:09 +02:00
|
|
|
|
|
|
|
-- This query should detect the broken connection when starting new remote
|
|
|
|
-- transaction, reestablish new connection, and then succeed.
|
|
|
|
BEGIN;
|
|
|
|
SELECT 1 FROM ft1 LIMIT 1;
|
|
|
|
|
2021-05-04 19:36:26 +02:00
|
|
|
-- If we detect the broken connection when starting a new remote
|
|
|
|
-- subtransaction, we should fail instead of establishing a new connection.
|
2021-04-14 07:23:53 +02:00
|
|
|
-- Terminate the remote connection and wait for the termination to complete.
|
Harden postgres_fdw tests against unexpected cache flushes.
postgres_fdw will close its remote session if an sinval cache reset
occurs, since it's possible that that means some FDW parameters
changed. We had two tests that were trying to ensure that the
session remains alive by setting debug_discard_caches = 0; but
that's not sufficient. Even though the tests seem stable enough
in the buildfarm, they flap a lot under CI.
In the first test, which is checking the ability to recover from
a lost connection, we can stabilize the results by just not
caring whether pg_terminate_backend() finds a victim backend.
If a reset did happen, there won't be a session to terminate
anymore, but the test can proceed anyway. (Arguably, we are
then not testing the unintentional-disconnect case, but as long
as that scenario is exercised in most runs I think it's fine;
testing the reset-driven case is of value too.)
In the second test, which is trying to verify the application_name
displayed in pg_stat_activity by a remote session, we had a race
condition in that the remote session might go away before we can
fetch its pg_stat_activity entry. We can close that race and make
the test more certainly test what it intends to by arranging things
so that the remote session itself fetches its pg_stat_activity entry
(based on PID rather than a somewhat-circular assumption about the
application name).
Both tests now demonstrably pass under debug_discard_caches = 1,
so we can remove that hack.
Back-patch into relevant back branches.
Discussion: https://postgr.es/m/20230226194340.u44bkfgyz64c67i6@awork3.anarazel.de
2023-02-27 22:29:51 +01:00
|
|
|
DO $$ BEGIN
|
|
|
|
PERFORM pg_terminate_backend(pid, 180000) FROM pg_stat_activity
|
2021-04-14 07:23:53 +02:00
|
|
|
WHERE application_name = 'fdw_retry_check';
|
Harden postgres_fdw tests against unexpected cache flushes.
postgres_fdw will close its remote session if an sinval cache reset
occurs, since it's possible that that means some FDW parameters
changed. We had two tests that were trying to ensure that the
session remains alive by setting debug_discard_caches = 0; but
that's not sufficient. Even though the tests seem stable enough
in the buildfarm, they flap a lot under CI.
In the first test, which is checking the ability to recover from
a lost connection, we can stabilize the results by just not
caring whether pg_terminate_backend() finds a victim backend.
If a reset did happen, there won't be a session to terminate
anymore, but the test can proceed anyway. (Arguably, we are
then not testing the unintentional-disconnect case, but as long
as that scenario is exercised in most runs I think it's fine;
testing the reset-driven case is of value too.)
In the second test, which is trying to verify the application_name
displayed in pg_stat_activity by a remote session, we had a race
condition in that the remote session might go away before we can
fetch its pg_stat_activity entry. We can close that race and make
the test more certainly test what it intends to by arranging things
so that the remote session itself fetches its pg_stat_activity entry
(based on PID rather than a somewhat-circular assumption about the
application name).
Both tests now demonstrably pass under debug_discard_caches = 1,
so we can remove that hack.
Back-patch into relevant back branches.
Discussion: https://postgr.es/m/20230226194340.u44bkfgyz64c67i6@awork3.anarazel.de
2023-02-27 22:29:51 +01:00
|
|
|
END $$;
|
2020-10-06 03:31:09 +02:00
|
|
|
SAVEPOINT s;
|
2021-05-04 19:36:26 +02:00
|
|
|
-- The text of the error might vary across platforms, so only show SQLSTATE.
|
2020-10-11 01:57:25 +02:00
|
|
|
\set VERBOSITY sqlstate
|
2020-10-06 03:31:09 +02:00
|
|
|
SELECT 1 FROM ft1 LIMIT 1; -- should fail
|
2020-10-11 01:57:25 +02:00
|
|
|
\set VERBOSITY default
|
2020-10-06 03:31:09 +02:00
|
|
|
COMMIT;
|
|
|
|
|
2021-01-25 19:54:46 +01:00
|
|
|
-- =============================================================================
|
|
|
|
-- test connection invalidation cases and postgres_fdw_get_connections function
|
|
|
|
-- =============================================================================
|
2021-01-30 02:12:22 +01:00
|
|
|
-- Let's ensure to close all the existing cached connections.
|
|
|
|
SELECT 1 FROM postgres_fdw_disconnect_all();
|
|
|
|
-- No cached connections, so no records should be output.
|
|
|
|
SELECT server_name FROM postgres_fdw_get_connections() ORDER BY 1;
|
2020-12-28 11:56:13 +01:00
|
|
|
-- This test case is for closing the connection in pgfdw_xact_callback
|
|
|
|
BEGIN;
|
|
|
|
-- Connection xact depth becomes 1 i.e. the connection is in midst of the xact.
|
|
|
|
SELECT 1 FROM ft1 LIMIT 1;
|
2021-01-18 07:11:08 +01:00
|
|
|
SELECT 1 FROM ft7 LIMIT 1;
|
2021-01-30 02:12:22 +01:00
|
|
|
-- List all the existing cached connections. loopback and loopback3 should be
|
|
|
|
-- output.
|
|
|
|
SELECT server_name FROM postgres_fdw_get_connections() ORDER BY 1;
|
|
|
|
-- Connections are not closed at the end of the alter and drop statements.
|
|
|
|
-- That's because the connections are in midst of this xact,
|
|
|
|
-- they are just marked as invalid in pgfdw_inval_callback.
|
2020-12-28 11:56:13 +01:00
|
|
|
ALTER SERVER loopback OPTIONS (ADD use_remote_estimate 'off');
|
2021-01-18 07:11:08 +01:00
|
|
|
DROP SERVER loopback3 CASCADE;
|
|
|
|
-- List all the existing cached connections. loopback and loopback3
|
|
|
|
-- should be output as invalid connections. Also the server name for
|
|
|
|
-- loopback3 should be NULL because the server was dropped.
|
|
|
|
SELECT * FROM postgres_fdw_get_connections() ORDER BY 1;
|
2021-01-30 02:12:22 +01:00
|
|
|
-- The invalid connections get closed in pgfdw_xact_callback during commit.
|
2020-12-28 11:56:13 +01:00
|
|
|
COMMIT;
|
2021-01-30 02:12:22 +01:00
|
|
|
-- All cached connections were closed while committing above xact, so no
|
|
|
|
-- records should be output.
|
|
|
|
SELECT server_name FROM postgres_fdw_get_connections() ORDER BY 1;
|
2021-01-20 23:05:46 +01:00
|
|
|
|
2021-01-25 19:54:46 +01:00
|
|
|
-- =======================================================================
|
|
|
|
-- test postgres_fdw_disconnect and postgres_fdw_disconnect_all functions
|
|
|
|
-- =======================================================================
|
2021-01-30 02:12:22 +01:00
|
|
|
BEGIN;
|
2021-01-25 19:54:46 +01:00
|
|
|
-- Ensure to cache loopback connection.
|
|
|
|
SELECT 1 FROM ft1 LIMIT 1;
|
|
|
|
-- Ensure to cache loopback2 connection.
|
|
|
|
SELECT 1 FROM ft6 LIMIT 1;
|
|
|
|
-- List all the existing cached connections. loopback and loopback2 should be
|
|
|
|
-- output.
|
2021-01-30 02:12:22 +01:00
|
|
|
SELECT server_name FROM postgres_fdw_get_connections() ORDER BY 1;
|
|
|
|
-- Issue a warning and return false as loopback connection is still in use and
|
2021-01-25 19:54:46 +01:00
|
|
|
-- can not be closed.
|
2021-01-30 02:12:22 +01:00
|
|
|
SELECT postgres_fdw_disconnect('loopback');
|
|
|
|
-- List all the existing cached connections. loopback and loopback2 should be
|
|
|
|
-- output.
|
|
|
|
SELECT server_name FROM postgres_fdw_get_connections() ORDER BY 1;
|
2021-01-25 19:54:46 +01:00
|
|
|
-- Return false as connections are still in use, warnings are issued.
|
2021-01-26 08:36:21 +01:00
|
|
|
-- But disable warnings temporarily because the order of them is not stable.
|
|
|
|
SET client_min_messages = 'ERROR';
|
2021-01-25 19:54:46 +01:00
|
|
|
SELECT postgres_fdw_disconnect_all();
|
2021-01-26 08:36:21 +01:00
|
|
|
RESET client_min_messages;
|
2021-01-25 19:54:46 +01:00
|
|
|
COMMIT;
|
2021-01-30 02:12:22 +01:00
|
|
|
-- Ensure that loopback2 connection is closed.
|
|
|
|
SELECT 1 FROM postgres_fdw_disconnect('loopback2');
|
|
|
|
SELECT server_name FROM postgres_fdw_get_connections() WHERE server_name = 'loopback2';
|
|
|
|
-- Return false as loopback2 connection is closed already.
|
2021-01-25 19:54:46 +01:00
|
|
|
SELECT postgres_fdw_disconnect('loopback2');
|
|
|
|
-- Return an error as there is no foreign server with given name.
|
|
|
|
SELECT postgres_fdw_disconnect('unknownserver');
|
2021-01-30 02:12:22 +01:00
|
|
|
-- Let's ensure to close all the existing cached connections.
|
|
|
|
SELECT 1 FROM postgres_fdw_disconnect_all();
|
|
|
|
-- No cached connections, so no records should be output.
|
|
|
|
SELECT server_name FROM postgres_fdw_get_connections() ORDER BY 1;
|
2021-01-25 19:54:46 +01:00
|
|
|
|
|
|
|
-- =============================================================================
|
|
|
|
-- test case for having multiple cached connections for a foreign server
|
|
|
|
-- =============================================================================
|
2021-01-26 09:16:52 +01:00
|
|
|
CREATE ROLE regress_multi_conn_user1 SUPERUSER;
|
|
|
|
CREATE ROLE regress_multi_conn_user2 SUPERUSER;
|
|
|
|
CREATE USER MAPPING FOR regress_multi_conn_user1 SERVER loopback;
|
|
|
|
CREATE USER MAPPING FOR regress_multi_conn_user2 SERVER loopback;
|
2021-01-25 19:54:46 +01:00
|
|
|
|
2021-01-30 02:12:22 +01:00
|
|
|
BEGIN;
|
2021-01-26 09:16:52 +01:00
|
|
|
-- Will cache loopback connection with user mapping for regress_multi_conn_user1
|
|
|
|
SET ROLE regress_multi_conn_user1;
|
2021-01-25 19:54:46 +01:00
|
|
|
SELECT 1 FROM ft1 LIMIT 1;
|
|
|
|
RESET ROLE;
|
|
|
|
|
2021-01-26 09:16:52 +01:00
|
|
|
-- Will cache loopback connection with user mapping for regress_multi_conn_user2
|
|
|
|
SET ROLE regress_multi_conn_user2;
|
2021-01-25 19:54:46 +01:00
|
|
|
SELECT 1 FROM ft1 LIMIT 1;
|
|
|
|
RESET ROLE;
|
|
|
|
|
|
|
|
-- Should output two connections for loopback server
|
2021-01-30 02:12:22 +01:00
|
|
|
SELECT server_name FROM postgres_fdw_get_connections() ORDER BY 1;
|
|
|
|
COMMIT;
|
|
|
|
-- Let's ensure to close all the existing cached connections.
|
|
|
|
SELECT 1 FROM postgres_fdw_disconnect_all();
|
|
|
|
-- No cached connections, so no records should be output.
|
|
|
|
SELECT server_name FROM postgres_fdw_get_connections() ORDER BY 1;
|
2021-01-25 19:54:46 +01:00
|
|
|
|
|
|
|
-- Clean up
|
2021-01-26 09:16:52 +01:00
|
|
|
DROP USER MAPPING FOR regress_multi_conn_user1 SERVER loopback;
|
|
|
|
DROP USER MAPPING FOR regress_multi_conn_user2 SERVER loopback;
|
|
|
|
DROP ROLE regress_multi_conn_user1;
|
|
|
|
DROP ROLE regress_multi_conn_user2;
|
2021-01-25 19:54:46 +01:00
|
|
|
|
2021-04-02 12:45:42 +02:00
|
|
|
-- ===================================================================
|
|
|
|
-- Test foreign server level option keep_connections
|
|
|
|
-- ===================================================================
|
|
|
|
-- By default, the connections associated with foreign server are cached i.e.
|
|
|
|
-- keep_connections option is on. Set it to off.
|
|
|
|
ALTER SERVER loopback OPTIONS (keep_connections 'off');
|
|
|
|
-- connection to loopback server is closed at the end of xact
|
|
|
|
-- as keep_connections was set to off.
|
|
|
|
SELECT 1 FROM ft1 LIMIT 1;
|
|
|
|
-- No cached connections, so no records should be output.
|
|
|
|
SELECT server_name FROM postgres_fdw_get_connections() ORDER BY 1;
|
|
|
|
ALTER SERVER loopback OPTIONS (SET keep_connections 'on');
|
|
|
|
|
2021-01-20 23:05:46 +01:00
|
|
|
-- ===================================================================
|
|
|
|
-- batch insert
|
|
|
|
-- ===================================================================
|
|
|
|
|
|
|
|
BEGIN;
|
|
|
|
|
|
|
|
CREATE SERVER batch10 FOREIGN DATA WRAPPER postgres_fdw OPTIONS( batch_size '10' );
|
|
|
|
|
|
|
|
SELECT count(*)
|
|
|
|
FROM pg_foreign_server
|
|
|
|
WHERE srvname = 'batch10'
|
|
|
|
AND srvoptions @> array['batch_size=10'];
|
|
|
|
|
|
|
|
ALTER SERVER batch10 OPTIONS( SET batch_size '20' );
|
|
|
|
|
|
|
|
SELECT count(*)
|
|
|
|
FROM pg_foreign_server
|
|
|
|
WHERE srvname = 'batch10'
|
|
|
|
AND srvoptions @> array['batch_size=10'];
|
|
|
|
|
|
|
|
SELECT count(*)
|
|
|
|
FROM pg_foreign_server
|
|
|
|
WHERE srvname = 'batch10'
|
|
|
|
AND srvoptions @> array['batch_size=20'];
|
|
|
|
|
|
|
|
CREATE FOREIGN TABLE table30 ( x int ) SERVER batch10 OPTIONS ( batch_size '30' );
|
|
|
|
|
|
|
|
SELECT COUNT(*)
|
|
|
|
FROM pg_foreign_table
|
|
|
|
WHERE ftrelid = 'table30'::regclass
|
|
|
|
AND ftoptions @> array['batch_size=30'];
|
|
|
|
|
|
|
|
ALTER FOREIGN TABLE table30 OPTIONS ( SET batch_size '40');
|
|
|
|
|
|
|
|
SELECT COUNT(*)
|
|
|
|
FROM pg_foreign_table
|
|
|
|
WHERE ftrelid = 'table30'::regclass
|
|
|
|
AND ftoptions @> array['batch_size=30'];
|
|
|
|
|
|
|
|
SELECT COUNT(*)
|
|
|
|
FROM pg_foreign_table
|
|
|
|
WHERE ftrelid = 'table30'::regclass
|
|
|
|
AND ftoptions @> array['batch_size=40'];
|
|
|
|
|
|
|
|
ROLLBACK;
|
|
|
|
|
|
|
|
CREATE TABLE batch_table ( x int );
|
|
|
|
|
|
|
|
CREATE FOREIGN TABLE ftable ( x int ) SERVER loopback OPTIONS ( table_name 'batch_table', batch_size '10' );
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) INSERT INTO ftable SELECT * FROM generate_series(1, 10) i;
|
|
|
|
INSERT INTO ftable SELECT * FROM generate_series(1, 10) i;
|
|
|
|
INSERT INTO ftable SELECT * FROM generate_series(11, 31) i;
|
|
|
|
INSERT INTO ftable VALUES (32);
|
|
|
|
INSERT INTO ftable VALUES (33), (34);
|
|
|
|
SELECT COUNT(*) FROM ftable;
|
|
|
|
TRUNCATE batch_table;
|
|
|
|
DROP FOREIGN TABLE ftable;
|
|
|
|
|
2021-06-08 20:22:18 +02:00
|
|
|
-- try if large batches exceed max number of bind parameters
|
|
|
|
CREATE FOREIGN TABLE ftable ( x int ) SERVER loopback OPTIONS ( table_name 'batch_table', batch_size '100000' );
|
|
|
|
INSERT INTO ftable SELECT * FROM generate_series(1, 70000) i;
|
|
|
|
SELECT COUNT(*) FROM ftable;
|
|
|
|
TRUNCATE batch_table;
|
|
|
|
DROP FOREIGN TABLE ftable;
|
|
|
|
|
2021-01-20 23:05:46 +01:00
|
|
|
-- Disable batch insert
|
|
|
|
CREATE FOREIGN TABLE ftable ( x int ) SERVER loopback OPTIONS ( table_name 'batch_table', batch_size '1' );
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) INSERT INTO ftable VALUES (1), (2);
|
|
|
|
INSERT INTO ftable VALUES (1), (2);
|
|
|
|
SELECT COUNT(*) FROM ftable;
|
2022-04-21 08:30:00 +02:00
|
|
|
|
|
|
|
-- Disable batch inserting into foreign tables with BEFORE ROW INSERT triggers
|
|
|
|
-- even if the batch_size option is enabled.
|
|
|
|
ALTER FOREIGN TABLE ftable OPTIONS ( SET batch_size '10' );
|
|
|
|
CREATE TRIGGER trig_row_before BEFORE INSERT ON ftable
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE trigger_data(23,'skidoo');
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF) INSERT INTO ftable VALUES (3), (4);
|
|
|
|
INSERT INTO ftable VALUES (3), (4);
|
|
|
|
SELECT COUNT(*) FROM ftable;
|
|
|
|
|
|
|
|
-- Clean up
|
|
|
|
DROP TRIGGER trig_row_before ON ftable;
|
2021-01-20 23:05:46 +01:00
|
|
|
DROP FOREIGN TABLE ftable;
|
|
|
|
DROP TABLE batch_table;
|
|
|
|
|
|
|
|
-- Use partitioning
|
|
|
|
CREATE TABLE batch_table ( x int ) PARTITION BY HASH (x);
|
|
|
|
|
|
|
|
CREATE TABLE batch_table_p0 (LIKE batch_table);
|
|
|
|
CREATE FOREIGN TABLE batch_table_p0f
|
|
|
|
PARTITION OF batch_table
|
|
|
|
FOR VALUES WITH (MODULUS 3, REMAINDER 0)
|
|
|
|
SERVER loopback
|
|
|
|
OPTIONS (table_name 'batch_table_p0', batch_size '10');
|
|
|
|
|
|
|
|
CREATE TABLE batch_table_p1 (LIKE batch_table);
|
|
|
|
CREATE FOREIGN TABLE batch_table_p1f
|
|
|
|
PARTITION OF batch_table
|
|
|
|
FOR VALUES WITH (MODULUS 3, REMAINDER 1)
|
|
|
|
SERVER loopback
|
|
|
|
OPTIONS (table_name 'batch_table_p1', batch_size '1');
|
|
|
|
|
|
|
|
CREATE TABLE batch_table_p2
|
|
|
|
PARTITION OF batch_table
|
|
|
|
FOR VALUES WITH (MODULUS 3, REMAINDER 2);
|
|
|
|
|
|
|
|
INSERT INTO batch_table SELECT * FROM generate_series(1, 66) i;
|
|
|
|
SELECT COUNT(*) FROM batch_table;
|
|
|
|
|
Allow batching of inserts during cross-partition updates.
Commit 927f453a9 disallowed batching added by commit b663a4136 to be
used for the inserts performed as part of cross-partition updates of
partitioned tables, mainly because the previous code in
nodeModifyTable.c couldn't handle pending inserts into foreign-table
partitions that are also UPDATE target partitions. But we don't have
such a limitation anymore (cf. commit ffbb7e65a), so let's allow for
this by removing from execPartition.c the restriction added by commit
927f453a9 that batching is only allowed if the query command type is
CMD_INSERT.
In postgres_fdw, since commit 86dc90056 changed it to effectively
disable cross-partition updates in the case where a foreign-table
partition chosen to insert rows into is also an UPDATE target partition,
allow batching in the case where a foreign-table partition chosen to
do so is *not* also an UPDATE target partition. This is enabled by the
"batch_size" option added by commit b663a4136, which is disabled by
default.
This patch also adjusts the test case added by commit 927f453a9 to
confirm that the inserts performed as part of a cross-partition update
of a partitioned table indeed uses batching.
Amit Langote, reviewed and/or tested by Georgios Kokolatos, Zhihong Yu,
Bharath Rupireddy, Hou Zhijie, Vignesh C, and me.
Discussion: http://postgr.es/m/CA%2BHiwqH1Lz1yJmPs%3DaD-pzd_HLLynLHvq5iYeT9mB0bBV7oJ6w%40mail.gmail.com
2022-12-20 11:05:00 +01:00
|
|
|
-- Clean up
|
|
|
|
DROP TABLE batch_table;
|
|
|
|
DROP TABLE batch_table_p0;
|
|
|
|
DROP TABLE batch_table_p1;
|
|
|
|
|
|
|
|
-- Check that batched mode also works for some inserts made during
|
|
|
|
-- cross-partition updates
|
2021-02-18 00:02:00 +01:00
|
|
|
CREATE TABLE batch_cp_upd_test (a int) PARTITION BY LIST (a);
|
|
|
|
CREATE TABLE batch_cp_upd_test1 (LIKE batch_cp_upd_test);
|
|
|
|
CREATE FOREIGN TABLE batch_cp_upd_test1_f
|
|
|
|
PARTITION OF batch_cp_upd_test
|
|
|
|
FOR VALUES IN (1)
|
|
|
|
SERVER loopback
|
|
|
|
OPTIONS (table_name 'batch_cp_upd_test1', batch_size '10');
|
Allow batching of inserts during cross-partition updates.
Commit 927f453a9 disallowed batching added by commit b663a4136 to be
used for the inserts performed as part of cross-partition updates of
partitioned tables, mainly because the previous code in
nodeModifyTable.c couldn't handle pending inserts into foreign-table
partitions that are also UPDATE target partitions. But we don't have
such a limitation anymore (cf. commit ffbb7e65a), so let's allow for
this by removing from execPartition.c the restriction added by commit
927f453a9 that batching is only allowed if the query command type is
CMD_INSERT.
In postgres_fdw, since commit 86dc90056 changed it to effectively
disable cross-partition updates in the case where a foreign-table
partition chosen to insert rows into is also an UPDATE target partition,
allow batching in the case where a foreign-table partition chosen to
do so is *not* also an UPDATE target partition. This is enabled by the
"batch_size" option added by commit b663a4136, which is disabled by
default.
This patch also adjusts the test case added by commit 927f453a9 to
confirm that the inserts performed as part of a cross-partition update
of a partitioned table indeed uses batching.
Amit Langote, reviewed and/or tested by Georgios Kokolatos, Zhihong Yu,
Bharath Rupireddy, Hou Zhijie, Vignesh C, and me.
Discussion: http://postgr.es/m/CA%2BHiwqH1Lz1yJmPs%3DaD-pzd_HLLynLHvq5iYeT9mB0bBV7oJ6w%40mail.gmail.com
2022-12-20 11:05:00 +01:00
|
|
|
CREATE TABLE batch_cp_upd_test2 PARTITION OF batch_cp_upd_test
|
2021-02-18 00:02:00 +01:00
|
|
|
FOR VALUES IN (2);
|
Allow batching of inserts during cross-partition updates.
Commit 927f453a9 disallowed batching added by commit b663a4136 to be
used for the inserts performed as part of cross-partition updates of
partitioned tables, mainly because the previous code in
nodeModifyTable.c couldn't handle pending inserts into foreign-table
partitions that are also UPDATE target partitions. But we don't have
such a limitation anymore (cf. commit ffbb7e65a), so let's allow for
this by removing from execPartition.c the restriction added by commit
927f453a9 that batching is only allowed if the query command type is
CMD_INSERT.
In postgres_fdw, since commit 86dc90056 changed it to effectively
disable cross-partition updates in the case where a foreign-table
partition chosen to insert rows into is also an UPDATE target partition,
allow batching in the case where a foreign-table partition chosen to
do so is *not* also an UPDATE target partition. This is enabled by the
"batch_size" option added by commit b663a4136, which is disabled by
default.
This patch also adjusts the test case added by commit 927f453a9 to
confirm that the inserts performed as part of a cross-partition update
of a partitioned table indeed uses batching.
Amit Langote, reviewed and/or tested by Georgios Kokolatos, Zhihong Yu,
Bharath Rupireddy, Hou Zhijie, Vignesh C, and me.
Discussion: http://postgr.es/m/CA%2BHiwqH1Lz1yJmPs%3DaD-pzd_HLLynLHvq5iYeT9mB0bBV7oJ6w%40mail.gmail.com
2022-12-20 11:05:00 +01:00
|
|
|
CREATE TABLE batch_cp_upd_test3 (LIKE batch_cp_upd_test);
|
|
|
|
CREATE FOREIGN TABLE batch_cp_upd_test3_f
|
|
|
|
PARTITION OF batch_cp_upd_test
|
|
|
|
FOR VALUES IN (3)
|
|
|
|
SERVER loopback
|
|
|
|
OPTIONS (table_name 'batch_cp_upd_test3', batch_size '1');
|
|
|
|
|
|
|
|
-- Create statement triggers on remote tables that "log" any INSERTs
|
|
|
|
-- performed on them.
|
|
|
|
CREATE TABLE cmdlog (cmd text);
|
|
|
|
CREATE FUNCTION log_stmt() RETURNS TRIGGER LANGUAGE plpgsql AS $$
|
|
|
|
BEGIN INSERT INTO public.cmdlog VALUES (TG_OP || ' on ' || TG_RELNAME); RETURN NULL; END;
|
|
|
|
$$;
|
|
|
|
CREATE TRIGGER stmt_trig AFTER INSERT ON batch_cp_upd_test1
|
|
|
|
FOR EACH STATEMENT EXECUTE FUNCTION log_stmt();
|
|
|
|
CREATE TRIGGER stmt_trig AFTER INSERT ON batch_cp_upd_test3
|
|
|
|
FOR EACH STATEMENT EXECUTE FUNCTION log_stmt();
|
|
|
|
|
|
|
|
-- This update moves rows from the local partition 'batch_cp_upd_test2' to the
|
|
|
|
-- foreign partition 'batch_cp_upd_test1', one that has insert batching
|
|
|
|
-- enabled, so a single INSERT for both rows.
|
|
|
|
INSERT INTO batch_cp_upd_test VALUES (2), (2);
|
|
|
|
UPDATE batch_cp_upd_test t SET a = 1 FROM (VALUES (1), (2)) s(a) WHERE t.a = s.a AND s.a = 2;
|
|
|
|
|
|
|
|
-- This one moves rows from the local partition 'batch_cp_upd_test2' to the
|
|
|
|
-- foreign partition 'batch_cp_upd_test2', one that has insert batching
|
|
|
|
-- disabled, so separate INSERTs for the two rows.
|
|
|
|
INSERT INTO batch_cp_upd_test VALUES (2), (2);
|
|
|
|
UPDATE batch_cp_upd_test t SET a = 3 FROM (VALUES (1), (2)) s(a) WHERE t.a = s.a AND s.a = 2;
|
|
|
|
|
|
|
|
SELECT tableoid::regclass, * FROM batch_cp_upd_test ORDER BY 1;
|
2021-02-18 00:02:00 +01:00
|
|
|
|
Allow batching of inserts during cross-partition updates.
Commit 927f453a9 disallowed batching added by commit b663a4136 to be
used for the inserts performed as part of cross-partition updates of
partitioned tables, mainly because the previous code in
nodeModifyTable.c couldn't handle pending inserts into foreign-table
partitions that are also UPDATE target partitions. But we don't have
such a limitation anymore (cf. commit ffbb7e65a), so let's allow for
this by removing from execPartition.c the restriction added by commit
927f453a9 that batching is only allowed if the query command type is
CMD_INSERT.
In postgres_fdw, since commit 86dc90056 changed it to effectively
disable cross-partition updates in the case where a foreign-table
partition chosen to insert rows into is also an UPDATE target partition,
allow batching in the case where a foreign-table partition chosen to
do so is *not* also an UPDATE target partition. This is enabled by the
"batch_size" option added by commit b663a4136, which is disabled by
default.
This patch also adjusts the test case added by commit 927f453a9 to
confirm that the inserts performed as part of a cross-partition update
of a partitioned table indeed uses batching.
Amit Langote, reviewed and/or tested by Georgios Kokolatos, Zhihong Yu,
Bharath Rupireddy, Hou Zhijie, Vignesh C, and me.
Discussion: http://postgr.es/m/CA%2BHiwqH1Lz1yJmPs%3DaD-pzd_HLLynLHvq5iYeT9mB0bBV7oJ6w%40mail.gmail.com
2022-12-20 11:05:00 +01:00
|
|
|
-- Should see 1 INSERT on batch_cp_upd_test1 and 2 on batch_cp_upd_test3 as
|
|
|
|
-- described above.
|
|
|
|
SELECT * FROM cmdlog ORDER BY 1;
|
2021-02-18 00:02:00 +01:00
|
|
|
|
2021-01-20 23:05:46 +01:00
|
|
|
-- Clean up
|
Allow batching of inserts during cross-partition updates.
Commit 927f453a9 disallowed batching added by commit b663a4136 to be
used for the inserts performed as part of cross-partition updates of
partitioned tables, mainly because the previous code in
nodeModifyTable.c couldn't handle pending inserts into foreign-table
partitions that are also UPDATE target partitions. But we don't have
such a limitation anymore (cf. commit ffbb7e65a), so let's allow for
this by removing from execPartition.c the restriction added by commit
927f453a9 that batching is only allowed if the query command type is
CMD_INSERT.
In postgres_fdw, since commit 86dc90056 changed it to effectively
disable cross-partition updates in the case where a foreign-table
partition chosen to insert rows into is also an UPDATE target partition,
allow batching in the case where a foreign-table partition chosen to
do so is *not* also an UPDATE target partition. This is enabled by the
"batch_size" option added by commit b663a4136, which is disabled by
default.
This patch also adjusts the test case added by commit 927f453a9 to
confirm that the inserts performed as part of a cross-partition update
of a partitioned table indeed uses batching.
Amit Langote, reviewed and/or tested by Georgios Kokolatos, Zhihong Yu,
Bharath Rupireddy, Hou Zhijie, Vignesh C, and me.
Discussion: http://postgr.es/m/CA%2BHiwqH1Lz1yJmPs%3DaD-pzd_HLLynLHvq5iYeT9mB0bBV7oJ6w%40mail.gmail.com
2022-12-20 11:05:00 +01:00
|
|
|
DROP TABLE batch_cp_upd_test;
|
|
|
|
DROP TABLE batch_cp_upd_test1;
|
|
|
|
DROP TABLE batch_cp_upd_test3;
|
|
|
|
DROP TABLE cmdlog;
|
|
|
|
DROP FUNCTION log_stmt();
|
2021-06-16 22:53:31 +02:00
|
|
|
|
|
|
|
-- Use partitioning
|
|
|
|
ALTER SERVER loopback OPTIONS (ADD batch_size '10');
|
|
|
|
|
|
|
|
CREATE TABLE batch_table ( x int, field1 text, field2 text) PARTITION BY HASH (x);
|
|
|
|
|
|
|
|
CREATE TABLE batch_table_p0 (LIKE batch_table);
|
|
|
|
ALTER TABLE batch_table_p0 ADD CONSTRAINT p0_pkey PRIMARY KEY (x);
|
|
|
|
CREATE FOREIGN TABLE batch_table_p0f
|
|
|
|
PARTITION OF batch_table
|
|
|
|
FOR VALUES WITH (MODULUS 2, REMAINDER 0)
|
|
|
|
SERVER loopback
|
|
|
|
OPTIONS (table_name 'batch_table_p0');
|
|
|
|
|
|
|
|
CREATE TABLE batch_table_p1 (LIKE batch_table);
|
|
|
|
ALTER TABLE batch_table_p1 ADD CONSTRAINT p1_pkey PRIMARY KEY (x);
|
|
|
|
CREATE FOREIGN TABLE batch_table_p1f
|
|
|
|
PARTITION OF batch_table
|
|
|
|
FOR VALUES WITH (MODULUS 2, REMAINDER 1)
|
|
|
|
SERVER loopback
|
|
|
|
OPTIONS (table_name 'batch_table_p1');
|
|
|
|
|
|
|
|
INSERT INTO batch_table SELECT i, 'test'||i, 'test'|| i FROM generate_series(1, 50) i;
|
|
|
|
SELECT COUNT(*) FROM batch_table;
|
|
|
|
SELECT * FROM batch_table ORDER BY x;
|
|
|
|
|
Fix handling of pending inserts in nodeModifyTable.c.
Commit b663a4136, which allowed FDWs to INSERT rows in bulk, added to
nodeModifyTable.c code to flush pending inserts to the foreign-table
result relation(s) before completing processing of the ModifyTable node,
but the code failed to take into account the case where the INSERT query
has modifying CTEs, leading to incorrect results.
Also, that commit failed to flush pending inserts before firing BEFORE
ROW triggers so that rows are visible to such triggers.
In that commit we scanned through EState's
es_tuple_routing_result_relations or es_opened_result_relations list to
find the foreign-table result relations to which pending inserts are
flushed, but that would be inefficient in some cases. So to fix, 1) add
a List member to EState to record the insert-pending result relations,
and 2) modify nodeModifyTable.c so that it adds the foreign-table result
relation to the list in ExecInsert() if appropriate, and flushes pending
inserts properly using the list where needed.
While here, fix a copy-and-pasteo in a comment in ExecBatchInsert(),
which was added by that commit.
Back-patch to v14 where that commit appeared.
Discussion: https://postgr.es/m/CAPmGK16qutyCmyJJzgQOhfBq%3DNoGDqTB6O0QBZTihrbqre%2BoxA%40mail.gmail.com
2022-11-25 09:45:00 +01:00
|
|
|
-- Clean up
|
|
|
|
DROP TABLE batch_table;
|
|
|
|
DROP TABLE batch_table_p0;
|
|
|
|
DROP TABLE batch_table_p1;
|
|
|
|
|
2021-06-16 22:53:31 +02:00
|
|
|
ALTER SERVER loopback OPTIONS (DROP batch_size);
|
Add support for asynchronous execution.
This implements asynchronous execution, which runs multiple parts of a
non-parallel-aware Append concurrently rather than serially to improve
performance when possible. Currently, the only node type that can be
run concurrently is a ForeignScan that is an immediate child of such an
Append. In the case where such ForeignScans access data on different
remote servers, this would run those ForeignScans concurrently, and
overlap the remote operations to be performed simultaneously, so it'll
improve the performance especially when the operations involve
time-consuming ones such as remote join and remote aggregation.
We may extend this to other node types such as joins or aggregates over
ForeignScans in the future.
This also adds the support for postgres_fdw, which is enabled by the
table-level/server-level option "async_capable". The default is false.
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself. This commit
is mostly based on the patch proposed by Robert Haas, but also uses
stuff from the patch proposed by Kyotaro Horiguchi and from the patch
proposed by Thomas Munro. Reviewed by Kyotaro Horiguchi, Konstantin
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and
others.
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com
2021-03-31 11:45:00 +02:00
|
|
|
|
Fix handling of pending inserts in nodeModifyTable.c.
Commit b663a4136, which allowed FDWs to INSERT rows in bulk, added to
nodeModifyTable.c code to flush pending inserts to the foreign-table
result relation(s) before completing processing of the ModifyTable node,
but the code failed to take into account the case where the INSERT query
has modifying CTEs, leading to incorrect results.
Also, that commit failed to flush pending inserts before firing BEFORE
ROW triggers so that rows are visible to such triggers.
In that commit we scanned through EState's
es_tuple_routing_result_relations or es_opened_result_relations list to
find the foreign-table result relations to which pending inserts are
flushed, but that would be inefficient in some cases. So to fix, 1) add
a List member to EState to record the insert-pending result relations,
and 2) modify nodeModifyTable.c so that it adds the foreign-table result
relation to the list in ExecInsert() if appropriate, and flushes pending
inserts properly using the list where needed.
While here, fix a copy-and-pasteo in a comment in ExecBatchInsert(),
which was added by that commit.
Back-patch to v14 where that commit appeared.
Discussion: https://postgr.es/m/CAPmGK16qutyCmyJJzgQOhfBq%3DNoGDqTB6O0QBZTihrbqre%2BoxA%40mail.gmail.com
2022-11-25 09:45:00 +01:00
|
|
|
-- Test that pending inserts are handled properly when needed
|
|
|
|
CREATE TABLE batch_table (a text, b int);
|
|
|
|
CREATE FOREIGN TABLE ftable (a text, b int)
|
|
|
|
SERVER loopback
|
|
|
|
OPTIONS (table_name 'batch_table', batch_size '2');
|
|
|
|
CREATE TABLE ltable (a text, b int);
|
|
|
|
CREATE FUNCTION ftable_rowcount_trigf() RETURNS trigger LANGUAGE plpgsql AS
|
|
|
|
$$
|
|
|
|
begin
|
|
|
|
raise notice '%: there are % rows in ftable',
|
|
|
|
TG_NAME, (SELECT count(*) FROM ftable);
|
|
|
|
if TG_OP = 'DELETE' then
|
|
|
|
return OLD;
|
|
|
|
else
|
|
|
|
return NEW;
|
|
|
|
end if;
|
|
|
|
end;
|
|
|
|
$$;
|
|
|
|
CREATE TRIGGER ftable_rowcount_trigger
|
|
|
|
BEFORE INSERT OR UPDATE OR DELETE ON ltable
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE ftable_rowcount_trigf();
|
|
|
|
|
|
|
|
WITH t AS (
|
|
|
|
INSERT INTO ltable VALUES ('AAA', 42), ('BBB', 42) RETURNING *
|
|
|
|
)
|
|
|
|
INSERT INTO ftable SELECT * FROM t;
|
|
|
|
|
|
|
|
SELECT * FROM ltable;
|
|
|
|
SELECT * FROM ftable;
|
|
|
|
DELETE FROM ftable;
|
|
|
|
|
|
|
|
WITH t AS (
|
|
|
|
UPDATE ltable SET b = b + 100 RETURNING *
|
|
|
|
)
|
|
|
|
INSERT INTO ftable SELECT * FROM t;
|
|
|
|
|
|
|
|
SELECT * FROM ltable;
|
|
|
|
SELECT * FROM ftable;
|
|
|
|
DELETE FROM ftable;
|
|
|
|
|
|
|
|
WITH t AS (
|
|
|
|
DELETE FROM ltable RETURNING *
|
|
|
|
)
|
|
|
|
INSERT INTO ftable SELECT * FROM t;
|
|
|
|
|
|
|
|
SELECT * FROM ltable;
|
|
|
|
SELECT * FROM ftable;
|
|
|
|
DELETE FROM ftable;
|
|
|
|
|
|
|
|
-- Clean up
|
|
|
|
DROP FOREIGN TABLE ftable;
|
|
|
|
DROP TABLE batch_table;
|
|
|
|
DROP TRIGGER ftable_rowcount_trigger ON ltable;
|
|
|
|
DROP TABLE ltable;
|
|
|
|
|
|
|
|
CREATE TABLE parent (a text, b int) PARTITION BY LIST (a);
|
|
|
|
CREATE TABLE batch_table (a text, b int);
|
|
|
|
CREATE FOREIGN TABLE ftable
|
|
|
|
PARTITION OF parent
|
|
|
|
FOR VALUES IN ('AAA')
|
|
|
|
SERVER loopback
|
|
|
|
OPTIONS (table_name 'batch_table', batch_size '2');
|
|
|
|
CREATE TABLE ltable
|
|
|
|
PARTITION OF parent
|
|
|
|
FOR VALUES IN ('BBB');
|
|
|
|
CREATE TRIGGER ftable_rowcount_trigger
|
|
|
|
BEFORE INSERT ON ltable
|
|
|
|
FOR EACH ROW EXECUTE PROCEDURE ftable_rowcount_trigf();
|
|
|
|
|
|
|
|
INSERT INTO parent VALUES ('AAA', 42), ('BBB', 42), ('AAA', 42), ('BBB', 42);
|
|
|
|
|
|
|
|
SELECT tableoid::regclass, * FROM parent;
|
|
|
|
|
|
|
|
-- Clean up
|
|
|
|
DROP FOREIGN TABLE ftable;
|
|
|
|
DROP TABLE batch_table;
|
|
|
|
DROP TRIGGER ftable_rowcount_trigger ON ltable;
|
|
|
|
DROP TABLE ltable;
|
|
|
|
DROP TABLE parent;
|
|
|
|
DROP FUNCTION ftable_rowcount_trigf;
|
|
|
|
|
Add support for asynchronous execution.
This implements asynchronous execution, which runs multiple parts of a
non-parallel-aware Append concurrently rather than serially to improve
performance when possible. Currently, the only node type that can be
run concurrently is a ForeignScan that is an immediate child of such an
Append. In the case where such ForeignScans access data on different
remote servers, this would run those ForeignScans concurrently, and
overlap the remote operations to be performed simultaneously, so it'll
improve the performance especially when the operations involve
time-consuming ones such as remote join and remote aggregation.
We may extend this to other node types such as joins or aggregates over
ForeignScans in the future.
This also adds the support for postgres_fdw, which is enabled by the
table-level/server-level option "async_capable". The default is false.
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself. This commit
is mostly based on the patch proposed by Robert Haas, but also uses
stuff from the patch proposed by Kyotaro Horiguchi and from the patch
proposed by Thomas Munro. Reviewed by Kyotaro Horiguchi, Konstantin
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and
others.
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com
2021-03-31 11:45:00 +02:00
|
|
|
-- ===================================================================
|
|
|
|
-- test asynchronous execution
|
|
|
|
-- ===================================================================
|
|
|
|
|
|
|
|
ALTER SERVER loopback OPTIONS (DROP extensions);
|
|
|
|
ALTER SERVER loopback OPTIONS (ADD async_capable 'true');
|
|
|
|
ALTER SERVER loopback2 OPTIONS (ADD async_capable 'true');
|
|
|
|
|
|
|
|
CREATE TABLE async_pt (a int, b int, c text) PARTITION BY RANGE (a);
|
|
|
|
CREATE TABLE base_tbl1 (a int, b int, c text);
|
|
|
|
CREATE TABLE base_tbl2 (a int, b int, c text);
|
|
|
|
CREATE FOREIGN TABLE async_p1 PARTITION OF async_pt FOR VALUES FROM (1000) TO (2000)
|
|
|
|
SERVER loopback OPTIONS (table_name 'base_tbl1');
|
|
|
|
CREATE FOREIGN TABLE async_p2 PARTITION OF async_pt FOR VALUES FROM (2000) TO (3000)
|
|
|
|
SERVER loopback2 OPTIONS (table_name 'base_tbl2');
|
|
|
|
INSERT INTO async_p1 SELECT 1000 + i, i, to_char(i, 'FM0000') FROM generate_series(0, 999, 5) i;
|
|
|
|
INSERT INTO async_p2 SELECT 2000 + i, i, to_char(i, 'FM0000') FROM generate_series(0, 999, 5) i;
|
|
|
|
ANALYZE async_pt;
|
|
|
|
|
|
|
|
-- simple queries
|
|
|
|
CREATE TABLE result_tbl (a int, b int, c text);
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO result_tbl SELECT * FROM async_pt WHERE b % 100 = 0;
|
|
|
|
INSERT INTO result_tbl SELECT * FROM async_pt WHERE b % 100 = 0;
|
|
|
|
|
|
|
|
SELECT * FROM result_tbl ORDER BY a;
|
|
|
|
DELETE FROM result_tbl;
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO result_tbl SELECT * FROM async_pt WHERE b === 505;
|
|
|
|
INSERT INTO result_tbl SELECT * FROM async_pt WHERE b === 505;
|
|
|
|
|
|
|
|
SELECT * FROM result_tbl ORDER BY a;
|
|
|
|
DELETE FROM result_tbl;
|
|
|
|
|
2022-04-06 08:45:00 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO result_tbl SELECT a, b, 'AAA' || c FROM async_pt WHERE b === 505;
|
|
|
|
INSERT INTO result_tbl SELECT a, b, 'AAA' || c FROM async_pt WHERE b === 505;
|
|
|
|
|
|
|
|
SELECT * FROM result_tbl ORDER BY a;
|
|
|
|
DELETE FROM result_tbl;
|
|
|
|
|
Add support for asynchronous execution.
This implements asynchronous execution, which runs multiple parts of a
non-parallel-aware Append concurrently rather than serially to improve
performance when possible. Currently, the only node type that can be
run concurrently is a ForeignScan that is an immediate child of such an
Append. In the case where such ForeignScans access data on different
remote servers, this would run those ForeignScans concurrently, and
overlap the remote operations to be performed simultaneously, so it'll
improve the performance especially when the operations involve
time-consuming ones such as remote join and remote aggregation.
We may extend this to other node types such as joins or aggregates over
ForeignScans in the future.
This also adds the support for postgres_fdw, which is enabled by the
table-level/server-level option "async_capable". The default is false.
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself. This commit
is mostly based on the patch proposed by Robert Haas, but also uses
stuff from the patch proposed by Kyotaro Horiguchi and from the patch
proposed by Thomas Munro. Reviewed by Kyotaro Horiguchi, Konstantin
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and
others.
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com
2021-03-31 11:45:00 +02:00
|
|
|
-- Check case where multiple partitions use the same connection
|
|
|
|
CREATE TABLE base_tbl3 (a int, b int, c text);
|
|
|
|
CREATE FOREIGN TABLE async_p3 PARTITION OF async_pt FOR VALUES FROM (3000) TO (4000)
|
|
|
|
SERVER loopback2 OPTIONS (table_name 'base_tbl3');
|
|
|
|
INSERT INTO async_p3 SELECT 3000 + i, i, to_char(i, 'FM0000') FROM generate_series(0, 999, 5) i;
|
|
|
|
ANALYZE async_pt;
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO result_tbl SELECT * FROM async_pt WHERE b === 505;
|
|
|
|
INSERT INTO result_tbl SELECT * FROM async_pt WHERE b === 505;
|
|
|
|
|
|
|
|
SELECT * FROM result_tbl ORDER BY a;
|
|
|
|
DELETE FROM result_tbl;
|
|
|
|
|
|
|
|
DROP FOREIGN TABLE async_p3;
|
|
|
|
DROP TABLE base_tbl3;
|
|
|
|
|
|
|
|
-- Check case where the partitioned table has local/remote partitions
|
|
|
|
CREATE TABLE async_p3 PARTITION OF async_pt FOR VALUES FROM (3000) TO (4000);
|
|
|
|
INSERT INTO async_p3 SELECT 3000 + i, i, to_char(i, 'FM0000') FROM generate_series(0, 999, 5) i;
|
|
|
|
ANALYZE async_pt;
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO result_tbl SELECT * FROM async_pt WHERE b === 505;
|
|
|
|
INSERT INTO result_tbl SELECT * FROM async_pt WHERE b === 505;
|
|
|
|
|
|
|
|
SELECT * FROM result_tbl ORDER BY a;
|
|
|
|
DELETE FROM result_tbl;
|
|
|
|
|
|
|
|
-- partitionwise joins
|
|
|
|
SET enable_partitionwise_join TO true;
|
|
|
|
|
|
|
|
CREATE TABLE join_tbl (a1 int, b1 int, c1 text, a2 int, b2 int, c2 text);
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO join_tbl SELECT * FROM async_pt t1, async_pt t2 WHERE t1.a = t2.a AND t1.b = t2.b AND t1.b % 100 = 0;
|
|
|
|
INSERT INTO join_tbl SELECT * FROM async_pt t1, async_pt t2 WHERE t1.a = t2.a AND t1.b = t2.b AND t1.b % 100 = 0;
|
|
|
|
|
|
|
|
SELECT * FROM join_tbl ORDER BY a1;
|
|
|
|
DELETE FROM join_tbl;
|
|
|
|
|
2022-04-06 08:45:00 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO join_tbl SELECT t1.a, t1.b, 'AAA' || t1.c, t2.a, t2.b, 'AAA' || t2.c FROM async_pt t1, async_pt t2 WHERE t1.a = t2.a AND t1.b = t2.b AND t1.b % 100 = 0;
|
|
|
|
INSERT INTO join_tbl SELECT t1.a, t1.b, 'AAA' || t1.c, t2.a, t2.b, 'AAA' || t2.c FROM async_pt t1, async_pt t2 WHERE t1.a = t2.a AND t1.b = t2.b AND t1.b % 100 = 0;
|
|
|
|
|
|
|
|
SELECT * FROM join_tbl ORDER BY a1;
|
|
|
|
DELETE FROM join_tbl;
|
|
|
|
|
Add support for asynchronous execution.
This implements asynchronous execution, which runs multiple parts of a
non-parallel-aware Append concurrently rather than serially to improve
performance when possible. Currently, the only node type that can be
run concurrently is a ForeignScan that is an immediate child of such an
Append. In the case where such ForeignScans access data on different
remote servers, this would run those ForeignScans concurrently, and
overlap the remote operations to be performed simultaneously, so it'll
improve the performance especially when the operations involve
time-consuming ones such as remote join and remote aggregation.
We may extend this to other node types such as joins or aggregates over
ForeignScans in the future.
This also adds the support for postgres_fdw, which is enabled by the
table-level/server-level option "async_capable". The default is false.
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself. This commit
is mostly based on the patch proposed by Robert Haas, but also uses
stuff from the patch proposed by Kyotaro Horiguchi and from the patch
proposed by Thomas Munro. Reviewed by Kyotaro Horiguchi, Konstantin
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and
others.
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com
2021-03-31 11:45:00 +02:00
|
|
|
RESET enable_partitionwise_join;
|
|
|
|
|
2021-06-07 05:45:00 +02:00
|
|
|
-- Test rescan of an async Append node with do_exec_prune=false
|
|
|
|
SET enable_hashjoin TO false;
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO join_tbl SELECT * FROM async_p1 t1, async_pt t2 WHERE t1.a = t2.a AND t1.b = t2.b AND t1.b % 100 = 0;
|
|
|
|
INSERT INTO join_tbl SELECT * FROM async_p1 t1, async_pt t2 WHERE t1.a = t2.a AND t1.b = t2.b AND t1.b % 100 = 0;
|
|
|
|
|
|
|
|
SELECT * FROM join_tbl ORDER BY a1;
|
|
|
|
DELETE FROM join_tbl;
|
|
|
|
|
|
|
|
RESET enable_hashjoin;
|
|
|
|
|
Add support for asynchronous execution.
This implements asynchronous execution, which runs multiple parts of a
non-parallel-aware Append concurrently rather than serially to improve
performance when possible. Currently, the only node type that can be
run concurrently is a ForeignScan that is an immediate child of such an
Append. In the case where such ForeignScans access data on different
remote servers, this would run those ForeignScans concurrently, and
overlap the remote operations to be performed simultaneously, so it'll
improve the performance especially when the operations involve
time-consuming ones such as remote join and remote aggregation.
We may extend this to other node types such as joins or aggregates over
ForeignScans in the future.
This also adds the support for postgres_fdw, which is enabled by the
table-level/server-level option "async_capable". The default is false.
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself. This commit
is mostly based on the patch proposed by Robert Haas, but also uses
stuff from the patch proposed by Kyotaro Horiguchi and from the patch
proposed by Thomas Munro. Reviewed by Kyotaro Horiguchi, Konstantin
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and
others.
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com
2021-03-31 11:45:00 +02:00
|
|
|
-- Test interaction of async execution with plan-time partition pruning
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM async_pt WHERE a < 3000;
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM async_pt WHERE a < 2000;
|
|
|
|
|
|
|
|
-- Test interaction of async execution with run-time partition pruning
|
|
|
|
SET plan_cache_mode TO force_generic_plan;
|
|
|
|
|
|
|
|
PREPARE async_pt_query (int, int) AS
|
|
|
|
INSERT INTO result_tbl SELECT * FROM async_pt WHERE a < $1 AND b === $2;
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
EXECUTE async_pt_query (3000, 505);
|
|
|
|
EXECUTE async_pt_query (3000, 505);
|
|
|
|
|
|
|
|
SELECT * FROM result_tbl ORDER BY a;
|
|
|
|
DELETE FROM result_tbl;
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
EXECUTE async_pt_query (2000, 505);
|
|
|
|
EXECUTE async_pt_query (2000, 505);
|
|
|
|
|
|
|
|
SELECT * FROM result_tbl ORDER BY a;
|
|
|
|
DELETE FROM result_tbl;
|
|
|
|
|
|
|
|
RESET plan_cache_mode;
|
|
|
|
|
|
|
|
CREATE TABLE local_tbl(a int, b int, c text);
|
|
|
|
INSERT INTO local_tbl VALUES (1505, 505, 'foo'), (2505, 505, 'bar');
|
|
|
|
ANALYZE local_tbl;
|
|
|
|
|
|
|
|
CREATE INDEX base_tbl1_idx ON base_tbl1 (a);
|
|
|
|
CREATE INDEX base_tbl2_idx ON base_tbl2 (a);
|
|
|
|
CREATE INDEX async_p3_idx ON async_p3 (a);
|
|
|
|
ANALYZE base_tbl1;
|
|
|
|
ANALYZE base_tbl2;
|
|
|
|
ANALYZE async_p3;
|
|
|
|
|
|
|
|
ALTER FOREIGN TABLE async_p1 OPTIONS (use_remote_estimate 'true');
|
|
|
|
ALTER FOREIGN TABLE async_p2 OPTIONS (use_remote_estimate 'true');
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM local_tbl, async_pt WHERE local_tbl.a = async_pt.a AND local_tbl.c = 'bar';
|
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
|
|
|
|
SELECT * FROM local_tbl, async_pt WHERE local_tbl.a = async_pt.a AND local_tbl.c = 'bar';
|
|
|
|
SELECT * FROM local_tbl, async_pt WHERE local_tbl.a = async_pt.a AND local_tbl.c = 'bar';
|
|
|
|
|
|
|
|
ALTER FOREIGN TABLE async_p1 OPTIONS (DROP use_remote_estimate);
|
|
|
|
ALTER FOREIGN TABLE async_p2 OPTIONS (DROP use_remote_estimate);
|
|
|
|
|
|
|
|
DROP TABLE local_tbl;
|
|
|
|
DROP INDEX base_tbl1_idx;
|
|
|
|
DROP INDEX base_tbl2_idx;
|
|
|
|
DROP INDEX async_p3_idx;
|
|
|
|
|
2022-04-06 08:45:00 +02:00
|
|
|
-- UNION queries
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO result_tbl
|
|
|
|
(SELECT a, b, 'AAA' || c FROM async_p1 ORDER BY a LIMIT 10)
|
|
|
|
UNION
|
|
|
|
(SELECT a, b, 'AAA' || c FROM async_p2 WHERE b < 10);
|
|
|
|
INSERT INTO result_tbl
|
|
|
|
(SELECT a, b, 'AAA' || c FROM async_p1 ORDER BY a LIMIT 10)
|
|
|
|
UNION
|
|
|
|
(SELECT a, b, 'AAA' || c FROM async_p2 WHERE b < 10);
|
|
|
|
|
|
|
|
SELECT * FROM result_tbl ORDER BY a;
|
|
|
|
DELETE FROM result_tbl;
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO result_tbl
|
|
|
|
(SELECT a, b, 'AAA' || c FROM async_p1 ORDER BY a LIMIT 10)
|
|
|
|
UNION ALL
|
|
|
|
(SELECT a, b, 'AAA' || c FROM async_p2 WHERE b < 10);
|
|
|
|
INSERT INTO result_tbl
|
|
|
|
(SELECT a, b, 'AAA' || c FROM async_p1 ORDER BY a LIMIT 10)
|
|
|
|
UNION ALL
|
|
|
|
(SELECT a, b, 'AAA' || c FROM async_p2 WHERE b < 10);
|
|
|
|
|
|
|
|
SELECT * FROM result_tbl ORDER BY a;
|
|
|
|
DELETE FROM result_tbl;
|
|
|
|
|
Disable asynchronous execution if using gating Result nodes.
mark_async_capable_plan(), which is called from create_append_plan() to
determine whether subplans are async-capable, failed to take into
account that the given subplan created from a given subpath might
include a gating Result node if the subpath is a SubqueryScanPath or
ForeignPath, causing a segmentation fault there when the subplan created
from a SubqueryScanPath includes the Result node, or causing
ExecAsyncRequest() to throw an error about an unrecognized node type
when the subplan created from a ForeignPath includes the Result node,
because in the latter case the Result node was unintentionally
considered as async-capable, but we don't currently support executing
Result nodes asynchronously. Fix by modifying mark_async_capable_plan()
to disable asynchronous execution in such cases. Also, adjust code in
the ProjectionPath case in mark_async_capable_plan(), for consistency
with other cases, and adjust/improve comments there.
is_async_capable_path() added in commit 27e1f1456, which was rewritten
to mark_async_capable_plan() in a later commit, has the same issue,
causing the error at execution mentioned above, so back-patch to v14
where the aforesaid commit went in.
Per report from Justin Pryzby.
Etsuro Fujita, reviewed by Zhihong Yu and Justin Pryzby.
Discussion: https://postgr.es/m/20220408124338.GK24419%40telsasoft.com
2022-04-28 08:15:00 +02:00
|
|
|
-- Disable async execution if we use gating Result nodes for pseudoconstant
|
|
|
|
-- quals
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM async_pt WHERE CURRENT_USER = SESSION_USER;
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
(SELECT * FROM async_p1 WHERE CURRENT_USER = SESSION_USER)
|
|
|
|
UNION ALL
|
|
|
|
(SELECT * FROM async_p2 WHERE CURRENT_USER = SESSION_USER);
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM ((SELECT * FROM async_p1 WHERE b < 10) UNION ALL (SELECT * FROM async_p2 WHERE b < 10)) s WHERE CURRENT_USER = SESSION_USER;
|
|
|
|
|
Add support for asynchronous execution.
This implements asynchronous execution, which runs multiple parts of a
non-parallel-aware Append concurrently rather than serially to improve
performance when possible. Currently, the only node type that can be
run concurrently is a ForeignScan that is an immediate child of such an
Append. In the case where such ForeignScans access data on different
remote servers, this would run those ForeignScans concurrently, and
overlap the remote operations to be performed simultaneously, so it'll
improve the performance especially when the operations involve
time-consuming ones such as remote join and remote aggregation.
We may extend this to other node types such as joins or aggregates over
ForeignScans in the future.
This also adds the support for postgres_fdw, which is enabled by the
table-level/server-level option "async_capable". The default is false.
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself. This commit
is mostly based on the patch proposed by Robert Haas, but also uses
stuff from the patch proposed by Kyotaro Horiguchi and from the patch
proposed by Thomas Munro. Reviewed by Kyotaro Horiguchi, Konstantin
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and
others.
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com
2021-03-31 11:45:00 +02:00
|
|
|
-- Test that pending requests are processed properly
|
|
|
|
SET enable_mergejoin TO false;
|
|
|
|
SET enable_hashjoin TO false;
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM async_pt t1, async_p2 t2 WHERE t1.a = t2.a AND t1.b === 505;
|
|
|
|
SELECT * FROM async_pt t1, async_p2 t2 WHERE t1.a = t2.a AND t1.b === 505;
|
|
|
|
|
2021-07-30 10:00:00 +02:00
|
|
|
CREATE TABLE local_tbl (a int, b int, c text);
|
|
|
|
INSERT INTO local_tbl VALUES (1505, 505, 'foo');
|
|
|
|
ANALYZE local_tbl;
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM local_tbl t1 LEFT JOIN (SELECT *, (SELECT count(*) FROM async_pt WHERE a < 3000) FROM async_pt WHERE a < 3000) t2 ON t1.a = t2.a;
|
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
|
|
|
|
SELECT * FROM local_tbl t1 LEFT JOIN (SELECT *, (SELECT count(*) FROM async_pt WHERE a < 3000) FROM async_pt WHERE a < 3000) t2 ON t1.a = t2.a;
|
|
|
|
SELECT * FROM local_tbl t1 LEFT JOIN (SELECT *, (SELECT count(*) FROM async_pt WHERE a < 3000) FROM async_pt WHERE a < 3000) t2 ON t1.a = t2.a;
|
|
|
|
|
Add support for asynchronous execution.
This implements asynchronous execution, which runs multiple parts of a
non-parallel-aware Append concurrently rather than serially to improve
performance when possible. Currently, the only node type that can be
run concurrently is a ForeignScan that is an immediate child of such an
Append. In the case where such ForeignScans access data on different
remote servers, this would run those ForeignScans concurrently, and
overlap the remote operations to be performed simultaneously, so it'll
improve the performance especially when the operations involve
time-consuming ones such as remote join and remote aggregation.
We may extend this to other node types such as joins or aggregates over
ForeignScans in the future.
This also adds the support for postgres_fdw, which is enabled by the
table-level/server-level option "async_capable". The default is false.
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself. This commit
is mostly based on the patch proposed by Robert Haas, but also uses
stuff from the patch proposed by Kyotaro Horiguchi and from the patch
proposed by Thomas Munro. Reviewed by Kyotaro Horiguchi, Konstantin
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and
others.
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com
2021-03-31 11:45:00 +02:00
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT * FROM async_pt t1 WHERE t1.b === 505 LIMIT 1;
|
2021-05-12 07:00:00 +02:00
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
|
|
|
|
SELECT * FROM async_pt t1 WHERE t1.b === 505 LIMIT 1;
|
Add support for asynchronous execution.
This implements asynchronous execution, which runs multiple parts of a
non-parallel-aware Append concurrently rather than serially to improve
performance when possible. Currently, the only node type that can be
run concurrently is a ForeignScan that is an immediate child of such an
Append. In the case where such ForeignScans access data on different
remote servers, this would run those ForeignScans concurrently, and
overlap the remote operations to be performed simultaneously, so it'll
improve the performance especially when the operations involve
time-consuming ones such as remote join and remote aggregation.
We may extend this to other node types such as joins or aggregates over
ForeignScans in the future.
This also adds the support for postgres_fdw, which is enabled by the
table-level/server-level option "async_capable". The default is false.
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself. This commit
is mostly based on the patch proposed by Robert Haas, but also uses
stuff from the patch proposed by Kyotaro Horiguchi and from the patch
proposed by Thomas Munro. Reviewed by Kyotaro Horiguchi, Konstantin
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and
others.
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com
2021-03-31 11:45:00 +02:00
|
|
|
SELECT * FROM async_pt t1 WHERE t1.b === 505 LIMIT 1;
|
|
|
|
|
|
|
|
-- Check with foreign modify
|
|
|
|
CREATE TABLE base_tbl3 (a int, b int, c text);
|
|
|
|
CREATE FOREIGN TABLE remote_tbl (a int, b int, c text)
|
|
|
|
SERVER loopback OPTIONS (table_name 'base_tbl3');
|
|
|
|
INSERT INTO remote_tbl VALUES (2505, 505, 'bar');
|
|
|
|
|
|
|
|
CREATE TABLE base_tbl4 (a int, b int, c text);
|
|
|
|
CREATE FOREIGN TABLE insert_tbl (a int, b int, c text)
|
|
|
|
SERVER loopback OPTIONS (table_name 'base_tbl4');
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
INSERT INTO insert_tbl (SELECT * FROM local_tbl UNION ALL SELECT * FROM remote_tbl);
|
|
|
|
INSERT INTO insert_tbl (SELECT * FROM local_tbl UNION ALL SELECT * FROM remote_tbl);
|
|
|
|
|
|
|
|
SELECT * FROM insert_tbl ORDER BY a;
|
|
|
|
|
|
|
|
-- Check with direct modify
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
WITH t AS (UPDATE remote_tbl SET c = c || c RETURNING *)
|
|
|
|
INSERT INTO join_tbl SELECT * FROM async_pt LEFT JOIN t ON (async_pt.a = t.a AND async_pt.b = t.b) WHERE async_pt.b === 505;
|
|
|
|
WITH t AS (UPDATE remote_tbl SET c = c || c RETURNING *)
|
|
|
|
INSERT INTO join_tbl SELECT * FROM async_pt LEFT JOIN t ON (async_pt.a = t.a AND async_pt.b = t.b) WHERE async_pt.b === 505;
|
|
|
|
|
|
|
|
SELECT * FROM join_tbl ORDER BY a1;
|
|
|
|
DELETE FROM join_tbl;
|
|
|
|
|
2021-05-12 07:00:00 +02:00
|
|
|
DROP TABLE local_tbl;
|
|
|
|
DROP FOREIGN TABLE remote_tbl;
|
|
|
|
DROP FOREIGN TABLE insert_tbl;
|
|
|
|
DROP TABLE base_tbl3;
|
|
|
|
DROP TABLE base_tbl4;
|
|
|
|
|
Add support for asynchronous execution.
This implements asynchronous execution, which runs multiple parts of a
non-parallel-aware Append concurrently rather than serially to improve
performance when possible. Currently, the only node type that can be
run concurrently is a ForeignScan that is an immediate child of such an
Append. In the case where such ForeignScans access data on different
remote servers, this would run those ForeignScans concurrently, and
overlap the remote operations to be performed simultaneously, so it'll
improve the performance especially when the operations involve
time-consuming ones such as remote join and remote aggregation.
We may extend this to other node types such as joins or aggregates over
ForeignScans in the future.
This also adds the support for postgres_fdw, which is enabled by the
table-level/server-level option "async_capable". The default is false.
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself. This commit
is mostly based on the patch proposed by Robert Haas, but also uses
stuff from the patch proposed by Kyotaro Horiguchi and from the patch
proposed by Thomas Munro. Reviewed by Kyotaro Horiguchi, Konstantin
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and
others.
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com
2021-03-31 11:45:00 +02:00
|
|
|
RESET enable_mergejoin;
|
|
|
|
RESET enable_hashjoin;
|
|
|
|
|
2021-05-13 13:00:00 +02:00
|
|
|
-- Test that UPDATE/DELETE with inherited target works with async_capable enabled
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
UPDATE async_pt SET c = c || c WHERE b = 0 RETURNING *;
|
|
|
|
UPDATE async_pt SET c = c || c WHERE b = 0 RETURNING *;
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
DELETE FROM async_pt WHERE b = 0 RETURNING *;
|
|
|
|
DELETE FROM async_pt WHERE b = 0 RETURNING *;
|
|
|
|
|
2021-05-12 07:00:00 +02:00
|
|
|
-- Check EXPLAIN ANALYZE for a query that scans empty partitions asynchronously
|
|
|
|
DELETE FROM async_p1;
|
|
|
|
DELETE FROM async_p2;
|
|
|
|
DELETE FROM async_p3;
|
|
|
|
|
|
|
|
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
|
|
|
|
SELECT * FROM async_pt;
|
|
|
|
|
Add support for asynchronous execution.
This implements asynchronous execution, which runs multiple parts of a
non-parallel-aware Append concurrently rather than serially to improve
performance when possible. Currently, the only node type that can be
run concurrently is a ForeignScan that is an immediate child of such an
Append. In the case where such ForeignScans access data on different
remote servers, this would run those ForeignScans concurrently, and
overlap the remote operations to be performed simultaneously, so it'll
improve the performance especially when the operations involve
time-consuming ones such as remote join and remote aggregation.
We may extend this to other node types such as joins or aggregates over
ForeignScans in the future.
This also adds the support for postgres_fdw, which is enabled by the
table-level/server-level option "async_capable". The default is false.
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself. This commit
is mostly based on the patch proposed by Robert Haas, but also uses
stuff from the patch proposed by Kyotaro Horiguchi and from the patch
proposed by Thomas Munro. Reviewed by Kyotaro Horiguchi, Konstantin
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and
others.
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com
2021-03-31 11:45:00 +02:00
|
|
|
-- Clean up
|
|
|
|
DROP TABLE async_pt;
|
|
|
|
DROP TABLE base_tbl1;
|
|
|
|
DROP TABLE base_tbl2;
|
|
|
|
DROP TABLE result_tbl;
|
|
|
|
DROP TABLE join_tbl;
|
|
|
|
|
2022-01-27 08:15:00 +01:00
|
|
|
-- Test that an asynchronous fetch is processed before restarting the scan in
|
|
|
|
-- ReScanForeignScan
|
|
|
|
CREATE TABLE base_tbl (a int, b int);
|
|
|
|
INSERT INTO base_tbl VALUES (1, 11), (2, 22), (3, 33);
|
|
|
|
CREATE FOREIGN TABLE foreign_tbl (b int)
|
|
|
|
SERVER loopback OPTIONS (table_name 'base_tbl');
|
|
|
|
CREATE FOREIGN TABLE foreign_tbl2 () INHERITS (foreign_tbl)
|
|
|
|
SERVER loopback OPTIONS (table_name 'base_tbl');
|
|
|
|
|
|
|
|
EXPLAIN (VERBOSE, COSTS OFF)
|
|
|
|
SELECT a FROM base_tbl WHERE a IN (SELECT a FROM foreign_tbl);
|
|
|
|
SELECT a FROM base_tbl WHERE a IN (SELECT a FROM foreign_tbl);
|
|
|
|
|
|
|
|
-- Clean up
|
|
|
|
DROP FOREIGN TABLE foreign_tbl CASCADE;
|
|
|
|
DROP TABLE base_tbl;
|
|
|
|
|
Add support for asynchronous execution.
This implements asynchronous execution, which runs multiple parts of a
non-parallel-aware Append concurrently rather than serially to improve
performance when possible. Currently, the only node type that can be
run concurrently is a ForeignScan that is an immediate child of such an
Append. In the case where such ForeignScans access data on different
remote servers, this would run those ForeignScans concurrently, and
overlap the remote operations to be performed simultaneously, so it'll
improve the performance especially when the operations involve
time-consuming ones such as remote join and remote aggregation.
We may extend this to other node types such as joins or aggregates over
ForeignScans in the future.
This also adds the support for postgres_fdw, which is enabled by the
table-level/server-level option "async_capable". The default is false.
Robert Haas, Kyotaro Horiguchi, Thomas Munro, and myself. This commit
is mostly based on the patch proposed by Robert Haas, but also uses
stuff from the patch proposed by Kyotaro Horiguchi and from the patch
proposed by Thomas Munro. Reviewed by Kyotaro Horiguchi, Konstantin
Knizhnik, Andrey Lepikhov, Movead Li, Thomas Munro, Justin Pryzby, and
others.
Discussion: https://postgr.es/m/CA%2BTgmoaXQEt4tZ03FtQhnzeDEMzBck%2BLrni0UWHVVgOTnA6C1w%40mail.gmail.com
Discussion: https://postgr.es/m/CA%2BhUKGLBRyu0rHrDCMC4%3DRn3252gogyp1SjOgG8SEKKZv%3DFwfQ%40mail.gmail.com
Discussion: https://postgr.es/m/20200228.170650.667613673625155850.horikyota.ntt%40gmail.com
2021-03-31 11:45:00 +02:00
|
|
|
ALTER SERVER loopback OPTIONS (DROP async_capable);
|
|
|
|
ALTER SERVER loopback2 OPTIONS (DROP async_capable);
|
postgres_fdw: Tighten up allowed values for batch_size, fetch_size options.
Previously the values such as '100$%$#$#', '9,223,372,' were accepted and
treated as valid integers for postgres_fdw options batch_size and fetch_size.
Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options
for which an error is thrown. This was because endptr was not used
while converting strings to integers using strtol.
This commit changes the logic so that it uses parse_int function
instead of strtol as it serves the purpose by returning false in case
if it is unable to convert the string to integer. Note that
this function also rounds off the values such as '100.456' to 100 and
'100.567' or '100.678' to 101.
While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.
Since parse_int and parse_real are being used for reloptions and GUCs,
it is more appropriate to use in postgres_fdw rather than using strtol
and strtod directly.
Back-patch to v14.
Author: Bharath Rupireddy
Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com
2021-07-07 04:13:40 +02:00
|
|
|
|
|
|
|
-- ===================================================================
|
2021-10-26 17:46:52 +02:00
|
|
|
-- test invalid server, foreign table and foreign data wrapper options
|
postgres_fdw: Tighten up allowed values for batch_size, fetch_size options.
Previously the values such as '100$%$#$#', '9,223,372,' were accepted and
treated as valid integers for postgres_fdw options batch_size and fetch_size.
Whereas this is not the case with fdw_startup_cost and fdw_tuple_cost options
for which an error is thrown. This was because endptr was not used
while converting strings to integers using strtol.
This commit changes the logic so that it uses parse_int function
instead of strtol as it serves the purpose by returning false in case
if it is unable to convert the string to integer. Note that
this function also rounds off the values such as '100.456' to 100 and
'100.567' or '100.678' to 101.
While on this, use parse_real for fdw_startup_cost and fdw_tuple_cost options.
Since parse_int and parse_real are being used for reloptions and GUCs,
it is more appropriate to use in postgres_fdw rather than using strtol
and strtod directly.
Back-patch to v14.
Author: Bharath Rupireddy
Reviewed-by: Ashutosh Bapat, Tom Lane, Kyotaro Horiguchi, Fujii Masao
Discussion: https://postgr.es/m/CALj2ACVMO6wY5Pc4oe1OCgUOAtdjHuFsBDw8R5uoYR86eWFQDA@mail.gmail.com
2021-07-07 04:13:40 +02:00
|
|
|
-- ===================================================================
|
|
|
|
-- Invalid fdw_startup_cost option
|
|
|
|
CREATE SERVER inv_scst FOREIGN DATA WRAPPER postgres_fdw
|
|
|
|
OPTIONS(fdw_startup_cost '100$%$#$#');
|
|
|
|
-- Invalid fdw_tuple_cost option
|
|
|
|
CREATE SERVER inv_scst FOREIGN DATA WRAPPER postgres_fdw
|
|
|
|
OPTIONS(fdw_tuple_cost '100$%$#$#');
|
|
|
|
-- Invalid fetch_size option
|
|
|
|
CREATE FOREIGN TABLE inv_fsz (c1 int )
|
|
|
|
SERVER loopback OPTIONS (fetch_size '100$%$#$#');
|
|
|
|
-- Invalid batch_size option
|
|
|
|
CREATE FOREIGN TABLE inv_bsz (c1 int )
|
|
|
|
SERVER loopback OPTIONS (batch_size '100$%$#$#');
|
2021-10-26 17:46:52 +02:00
|
|
|
|
|
|
|
-- No option is allowed to be specified at foreign data wrapper level
|
|
|
|
ALTER FOREIGN DATA WRAPPER postgres_fdw OPTIONS (nonexistent 'fdw');
|
2022-01-07 07:31:56 +01:00
|
|
|
|
|
|
|
-- ===================================================================
|
|
|
|
-- test postgres_fdw.application_name GUC
|
|
|
|
-- ===================================================================
|
Harden postgres_fdw tests against unexpected cache flushes.
postgres_fdw will close its remote session if an sinval cache reset
occurs, since it's possible that that means some FDW parameters
changed. We had two tests that were trying to ensure that the
session remains alive by setting debug_discard_caches = 0; but
that's not sufficient. Even though the tests seem stable enough
in the buildfarm, they flap a lot under CI.
In the first test, which is checking the ability to recover from
a lost connection, we can stabilize the results by just not
caring whether pg_terminate_backend() finds a victim backend.
If a reset did happen, there won't be a session to terminate
anymore, but the test can proceed anyway. (Arguably, we are
then not testing the unintentional-disconnect case, but as long
as that scenario is exercised in most runs I think it's fine;
testing the reset-driven case is of value too.)
In the second test, which is trying to verify the application_name
displayed in pg_stat_activity by a remote session, we had a race
condition in that the remote session might go away before we can
fetch its pg_stat_activity entry. We can close that race and make
the test more certainly test what it intends to by arranging things
so that the remote session itself fetches its pg_stat_activity entry
(based on PID rather than a somewhat-circular assumption about the
application name).
Both tests now demonstrably pass under debug_discard_caches = 1,
so we can remove that hack.
Back-patch into relevant back branches.
Discussion: https://postgr.es/m/20230226194340.u44bkfgyz64c67i6@awork3.anarazel.de
2023-02-27 22:29:51 +01:00
|
|
|
-- To avoid race conditions in checking the remote session's application_name,
|
|
|
|
-- use this view to make the remote session itself read its application_name.
|
|
|
|
CREATE VIEW my_application_name AS
|
|
|
|
SELECT application_name FROM pg_stat_activity WHERE pid = pg_backend_pid();
|
|
|
|
|
|
|
|
CREATE FOREIGN TABLE remote_application_name (application_name text)
|
|
|
|
SERVER loopback2
|
|
|
|
OPTIONS (schema_name 'public', table_name 'my_application_name');
|
|
|
|
|
|
|
|
SELECT count(*) FROM remote_application_name;
|
2022-01-07 07:31:56 +01:00
|
|
|
|
|
|
|
-- Specify escape sequences in application_name option of a server
|
|
|
|
-- object so as to test that they are replaced with status information
|
Harden postgres_fdw tests against unexpected cache flushes.
postgres_fdw will close its remote session if an sinval cache reset
occurs, since it's possible that that means some FDW parameters
changed. We had two tests that were trying to ensure that the
session remains alive by setting debug_discard_caches = 0; but
that's not sufficient. Even though the tests seem stable enough
in the buildfarm, they flap a lot under CI.
In the first test, which is checking the ability to recover from
a lost connection, we can stabilize the results by just not
caring whether pg_terminate_backend() finds a victim backend.
If a reset did happen, there won't be a session to terminate
anymore, but the test can proceed anyway. (Arguably, we are
then not testing the unintentional-disconnect case, but as long
as that scenario is exercised in most runs I think it's fine;
testing the reset-driven case is of value too.)
In the second test, which is trying to verify the application_name
displayed in pg_stat_activity by a remote session, we had a race
condition in that the remote session might go away before we can
fetch its pg_stat_activity entry. We can close that race and make
the test more certainly test what it intends to by arranging things
so that the remote session itself fetches its pg_stat_activity entry
(based on PID rather than a somewhat-circular assumption about the
application name).
Both tests now demonstrably pass under debug_discard_caches = 1,
so we can remove that hack.
Back-patch into relevant back branches.
Discussion: https://postgr.es/m/20230226194340.u44bkfgyz64c67i6@awork3.anarazel.de
2023-02-27 22:29:51 +01:00
|
|
|
-- expectedly. Note that we are also relying on ALTER SERVER to force
|
|
|
|
-- the remote session to be restarted with its new application name.
|
2022-01-07 07:31:56 +01:00
|
|
|
--
|
|
|
|
-- Since pg_stat_activity.application_name may be truncated to less than
|
|
|
|
-- NAMEDATALEN characters, note that substring() needs to be used
|
|
|
|
-- at the condition of test query to make sure that the string consisting
|
|
|
|
-- of database name and process ID is also less than that.
|
|
|
|
ALTER SERVER loopback2 OPTIONS (application_name 'fdw_%d%p');
|
Harden postgres_fdw tests against unexpected cache flushes.
postgres_fdw will close its remote session if an sinval cache reset
occurs, since it's possible that that means some FDW parameters
changed. We had two tests that were trying to ensure that the
session remains alive by setting debug_discard_caches = 0; but
that's not sufficient. Even though the tests seem stable enough
in the buildfarm, they flap a lot under CI.
In the first test, which is checking the ability to recover from
a lost connection, we can stabilize the results by just not
caring whether pg_terminate_backend() finds a victim backend.
If a reset did happen, there won't be a session to terminate
anymore, but the test can proceed anyway. (Arguably, we are
then not testing the unintentional-disconnect case, but as long
as that scenario is exercised in most runs I think it's fine;
testing the reset-driven case is of value too.)
In the second test, which is trying to verify the application_name
displayed in pg_stat_activity by a remote session, we had a race
condition in that the remote session might go away before we can
fetch its pg_stat_activity entry. We can close that race and make
the test more certainly test what it intends to by arranging things
so that the remote session itself fetches its pg_stat_activity entry
(based on PID rather than a somewhat-circular assumption about the
application name).
Both tests now demonstrably pass under debug_discard_caches = 1,
so we can remove that hack.
Back-patch into relevant back branches.
Discussion: https://postgr.es/m/20230226194340.u44bkfgyz64c67i6@awork3.anarazel.de
2023-02-27 22:29:51 +01:00
|
|
|
SELECT count(*) FROM remote_application_name
|
2022-01-07 07:31:56 +01:00
|
|
|
WHERE application_name =
|
|
|
|
substring('fdw_' || current_database() || pg_backend_pid() for
|
|
|
|
current_setting('max_identifier_length')::int);
|
|
|
|
|
|
|
|
-- postgres_fdw.application_name overrides application_name option
|
|
|
|
-- of a server object if both settings are present.
|
Harden postgres_fdw tests against unexpected cache flushes.
postgres_fdw will close its remote session if an sinval cache reset
occurs, since it's possible that that means some FDW parameters
changed. We had two tests that were trying to ensure that the
session remains alive by setting debug_discard_caches = 0; but
that's not sufficient. Even though the tests seem stable enough
in the buildfarm, they flap a lot under CI.
In the first test, which is checking the ability to recover from
a lost connection, we can stabilize the results by just not
caring whether pg_terminate_backend() finds a victim backend.
If a reset did happen, there won't be a session to terminate
anymore, but the test can proceed anyway. (Arguably, we are
then not testing the unintentional-disconnect case, but as long
as that scenario is exercised in most runs I think it's fine;
testing the reset-driven case is of value too.)
In the second test, which is trying to verify the application_name
displayed in pg_stat_activity by a remote session, we had a race
condition in that the remote session might go away before we can
fetch its pg_stat_activity entry. We can close that race and make
the test more certainly test what it intends to by arranging things
so that the remote session itself fetches its pg_stat_activity entry
(based on PID rather than a somewhat-circular assumption about the
application name).
Both tests now demonstrably pass under debug_discard_caches = 1,
so we can remove that hack.
Back-patch into relevant back branches.
Discussion: https://postgr.es/m/20230226194340.u44bkfgyz64c67i6@awork3.anarazel.de
2023-02-27 22:29:51 +01:00
|
|
|
ALTER SERVER loopback2 OPTIONS (SET application_name 'fdw_wrong');
|
2022-01-07 07:31:56 +01:00
|
|
|
SET postgres_fdw.application_name TO 'fdw_%a%u%%';
|
Harden postgres_fdw tests against unexpected cache flushes.
postgres_fdw will close its remote session if an sinval cache reset
occurs, since it's possible that that means some FDW parameters
changed. We had two tests that were trying to ensure that the
session remains alive by setting debug_discard_caches = 0; but
that's not sufficient. Even though the tests seem stable enough
in the buildfarm, they flap a lot under CI.
In the first test, which is checking the ability to recover from
a lost connection, we can stabilize the results by just not
caring whether pg_terminate_backend() finds a victim backend.
If a reset did happen, there won't be a session to terminate
anymore, but the test can proceed anyway. (Arguably, we are
then not testing the unintentional-disconnect case, but as long
as that scenario is exercised in most runs I think it's fine;
testing the reset-driven case is of value too.)
In the second test, which is trying to verify the application_name
displayed in pg_stat_activity by a remote session, we had a race
condition in that the remote session might go away before we can
fetch its pg_stat_activity entry. We can close that race and make
the test more certainly test what it intends to by arranging things
so that the remote session itself fetches its pg_stat_activity entry
(based on PID rather than a somewhat-circular assumption about the
application name).
Both tests now demonstrably pass under debug_discard_caches = 1,
so we can remove that hack.
Back-patch into relevant back branches.
Discussion: https://postgr.es/m/20230226194340.u44bkfgyz64c67i6@awork3.anarazel.de
2023-02-27 22:29:51 +01:00
|
|
|
SELECT count(*) FROM remote_application_name
|
2022-01-07 07:31:56 +01:00
|
|
|
WHERE application_name =
|
|
|
|
substring('fdw_' || current_setting('application_name') ||
|
|
|
|
CURRENT_USER || '%' for current_setting('max_identifier_length')::int);
|
Harden postgres_fdw tests against unexpected cache flushes.
postgres_fdw will close its remote session if an sinval cache reset
occurs, since it's possible that that means some FDW parameters
changed. We had two tests that were trying to ensure that the
session remains alive by setting debug_discard_caches = 0; but
that's not sufficient. Even though the tests seem stable enough
in the buildfarm, they flap a lot under CI.
In the first test, which is checking the ability to recover from
a lost connection, we can stabilize the results by just not
caring whether pg_terminate_backend() finds a victim backend.
If a reset did happen, there won't be a session to terminate
anymore, but the test can proceed anyway. (Arguably, we are
then not testing the unintentional-disconnect case, but as long
as that scenario is exercised in most runs I think it's fine;
testing the reset-driven case is of value too.)
In the second test, which is trying to verify the application_name
displayed in pg_stat_activity by a remote session, we had a race
condition in that the remote session might go away before we can
fetch its pg_stat_activity entry. We can close that race and make
the test more certainly test what it intends to by arranging things
so that the remote session itself fetches its pg_stat_activity entry
(based on PID rather than a somewhat-circular assumption about the
application name).
Both tests now demonstrably pass under debug_discard_caches = 1,
so we can remove that hack.
Back-patch into relevant back branches.
Discussion: https://postgr.es/m/20230226194340.u44bkfgyz64c67i6@awork3.anarazel.de
2023-02-27 22:29:51 +01:00
|
|
|
RESET postgres_fdw.application_name;
|
2022-01-07 07:31:56 +01:00
|
|
|
|
2022-02-18 03:38:12 +01:00
|
|
|
-- Test %c (session ID) and %C (cluster name) escape sequences.
|
Harden postgres_fdw tests against unexpected cache flushes.
postgres_fdw will close its remote session if an sinval cache reset
occurs, since it's possible that that means some FDW parameters
changed. We had two tests that were trying to ensure that the
session remains alive by setting debug_discard_caches = 0; but
that's not sufficient. Even though the tests seem stable enough
in the buildfarm, they flap a lot under CI.
In the first test, which is checking the ability to recover from
a lost connection, we can stabilize the results by just not
caring whether pg_terminate_backend() finds a victim backend.
If a reset did happen, there won't be a session to terminate
anymore, but the test can proceed anyway. (Arguably, we are
then not testing the unintentional-disconnect case, but as long
as that scenario is exercised in most runs I think it's fine;
testing the reset-driven case is of value too.)
In the second test, which is trying to verify the application_name
displayed in pg_stat_activity by a remote session, we had a race
condition in that the remote session might go away before we can
fetch its pg_stat_activity entry. We can close that race and make
the test more certainly test what it intends to by arranging things
so that the remote session itself fetches its pg_stat_activity entry
(based on PID rather than a somewhat-circular assumption about the
application name).
Both tests now demonstrably pass under debug_discard_caches = 1,
so we can remove that hack.
Back-patch into relevant back branches.
Discussion: https://postgr.es/m/20230226194340.u44bkfgyz64c67i6@awork3.anarazel.de
2023-02-27 22:29:51 +01:00
|
|
|
ALTER SERVER loopback2 OPTIONS (SET application_name 'fdw_%C%c');
|
|
|
|
SELECT count(*) FROM remote_application_name
|
2022-02-18 03:38:12 +01:00
|
|
|
WHERE application_name =
|
|
|
|
substring('fdw_' || current_setting('cluster_name') ||
|
|
|
|
to_hex(trunc(EXTRACT(EPOCH FROM (SELECT backend_start FROM
|
|
|
|
pg_stat_get_activity(pg_backend_pid()))))::integer) || '.' ||
|
|
|
|
to_hex(pg_backend_pid())
|
|
|
|
for current_setting('max_identifier_length')::int);
|
|
|
|
|
2023-02-28 02:27:48 +01:00
|
|
|
-- Clean up.
|
|
|
|
DROP FOREIGN TABLE remote_application_name;
|
|
|
|
DROP VIEW my_application_name;
|
|
|
|
|
2022-02-24 06:30:00 +01:00
|
|
|
-- ===================================================================
|
2023-04-06 10:30:00 +02:00
|
|
|
-- test parallel commit and parallel abort
|
2022-02-24 06:30:00 +01:00
|
|
|
-- ===================================================================
|
|
|
|
ALTER SERVER loopback OPTIONS (ADD parallel_commit 'true');
|
2023-04-06 10:30:00 +02:00
|
|
|
ALTER SERVER loopback OPTIONS (ADD parallel_abort 'true');
|
2022-02-24 06:30:00 +01:00
|
|
|
ALTER SERVER loopback2 OPTIONS (ADD parallel_commit 'true');
|
2023-04-06 10:30:00 +02:00
|
|
|
ALTER SERVER loopback2 OPTIONS (ADD parallel_abort 'true');
|
2022-02-24 06:30:00 +01:00
|
|
|
|
|
|
|
CREATE TABLE ploc1 (f1 int, f2 text);
|
|
|
|
CREATE FOREIGN TABLE prem1 (f1 int, f2 text)
|
|
|
|
SERVER loopback OPTIONS (table_name 'ploc1');
|
|
|
|
CREATE TABLE ploc2 (f1 int, f2 text);
|
|
|
|
CREATE FOREIGN TABLE prem2 (f1 int, f2 text)
|
|
|
|
SERVER loopback2 OPTIONS (table_name 'ploc2');
|
|
|
|
|
|
|
|
BEGIN;
|
|
|
|
INSERT INTO prem1 VALUES (101, 'foo');
|
|
|
|
INSERT INTO prem2 VALUES (201, 'bar');
|
|
|
|
COMMIT;
|
|
|
|
SELECT * FROM prem1;
|
|
|
|
SELECT * FROM prem2;
|
|
|
|
|
|
|
|
BEGIN;
|
|
|
|
SAVEPOINT s;
|
|
|
|
INSERT INTO prem1 VALUES (102, 'foofoo');
|
|
|
|
INSERT INTO prem2 VALUES (202, 'barbar');
|
|
|
|
RELEASE SAVEPOINT s;
|
|
|
|
COMMIT;
|
|
|
|
SELECT * FROM prem1;
|
|
|
|
SELECT * FROM prem2;
|
|
|
|
|
|
|
|
-- This tests executing DEALLOCATE ALL against foreign servers in parallel
|
|
|
|
-- during pre-commit
|
|
|
|
BEGIN;
|
|
|
|
SAVEPOINT s;
|
|
|
|
INSERT INTO prem1 VALUES (103, 'baz');
|
|
|
|
INSERT INTO prem2 VALUES (203, 'qux');
|
|
|
|
ROLLBACK TO SAVEPOINT s;
|
|
|
|
RELEASE SAVEPOINT s;
|
|
|
|
INSERT INTO prem1 VALUES (104, 'bazbaz');
|
|
|
|
INSERT INTO prem2 VALUES (204, 'quxqux');
|
|
|
|
COMMIT;
|
|
|
|
SELECT * FROM prem1;
|
|
|
|
SELECT * FROM prem2;
|
|
|
|
|
2023-04-06 10:30:00 +02:00
|
|
|
BEGIN;
|
|
|
|
INSERT INTO prem1 VALUES (105, 'test1');
|
|
|
|
INSERT INTO prem2 VALUES (205, 'test2');
|
|
|
|
ABORT;
|
|
|
|
SELECT * FROM prem1;
|
|
|
|
SELECT * FROM prem2;
|
|
|
|
|
|
|
|
-- This tests executing DEALLOCATE ALL against foreign servers in parallel
|
|
|
|
-- during post-abort
|
|
|
|
BEGIN;
|
|
|
|
SAVEPOINT s;
|
|
|
|
INSERT INTO prem1 VALUES (105, 'test1');
|
|
|
|
INSERT INTO prem2 VALUES (205, 'test2');
|
|
|
|
ROLLBACK TO SAVEPOINT s;
|
|
|
|
RELEASE SAVEPOINT s;
|
|
|
|
INSERT INTO prem1 VALUES (105, 'test1');
|
|
|
|
INSERT INTO prem2 VALUES (205, 'test2');
|
|
|
|
ABORT;
|
|
|
|
SELECT * FROM prem1;
|
|
|
|
SELECT * FROM prem2;
|
|
|
|
|
2022-02-24 06:30:00 +01:00
|
|
|
ALTER SERVER loopback OPTIONS (DROP parallel_commit);
|
2023-04-06 10:30:00 +02:00
|
|
|
ALTER SERVER loopback OPTIONS (DROP parallel_abort);
|
2022-02-24 06:30:00 +01:00
|
|
|
ALTER SERVER loopback2 OPTIONS (DROP parallel_commit);
|
2023-04-06 10:30:00 +02:00
|
|
|
ALTER SERVER loopback2 OPTIONS (DROP parallel_abort);
|
2022-12-30 23:14:53 +01:00
|
|
|
|
|
|
|
-- ===================================================================
|
|
|
|
-- test for ANALYZE sampling
|
|
|
|
-- ===================================================================
|
|
|
|
|
|
|
|
CREATE TABLE analyze_table (id int, a text, b bigint);
|
|
|
|
|
|
|
|
CREATE FOREIGN TABLE analyze_ftable (id int, a text, b bigint)
|
|
|
|
SERVER loopback OPTIONS (table_name 'analyze_rtable1');
|
|
|
|
|
|
|
|
INSERT INTO analyze_table (SELECT x FROM generate_series(1,1000) x);
|
|
|
|
ANALYZE analyze_table;
|
|
|
|
|
|
|
|
SET default_statistics_target = 10;
|
|
|
|
ANALYZE analyze_table;
|
|
|
|
|
|
|
|
ALTER SERVER loopback OPTIONS (analyze_sampling 'invalid');
|
|
|
|
|
|
|
|
ALTER SERVER loopback OPTIONS (analyze_sampling 'auto');
|
|
|
|
ANALYZE analyze_table;
|
|
|
|
|
|
|
|
ALTER SERVER loopback OPTIONS (SET analyze_sampling 'system');
|
|
|
|
ANALYZE analyze_table;
|
|
|
|
|
|
|
|
ALTER SERVER loopback OPTIONS (SET analyze_sampling 'bernoulli');
|
|
|
|
ANALYZE analyze_table;
|
|
|
|
|
|
|
|
ALTER SERVER loopback OPTIONS (SET analyze_sampling 'random');
|
|
|
|
ANALYZE analyze_table;
|
|
|
|
|
|
|
|
ALTER SERVER loopback OPTIONS (SET analyze_sampling 'off');
|
|
|
|
ANALYZE analyze_table;
|
|
|
|
|
|
|
|
-- cleanup
|
|
|
|
DROP FOREIGN TABLE analyze_ftable;
|
|
|
|
DROP TABLE analyze_table;
|