From: Antonin Houska <ah@cybertec.at>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
cc: pgsql-hackers@postgresql.org
Subject: Re: asynchronous execution
In-reply-to: <20170622.141720.190958545.horiguchi.kyotaro@lab.ntt.co.jp>
References: <20170404.192539.29699823.horiguchi.kyotaro@lab.ntt.co.jp>
 <20170522.131214.20936668.horiguchi.kyotaro@lab.ntt.co.jp>
 <20170522.142253.40733906.horiguchi.kyotaro@lab.ntt.co.jp>
 <20170622.141720.190958545.horiguchi.kyotaro@lab.ntt.co.jp>
Comments: In-reply-to Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
   message dated "Thu, 22 Jun 2017 14:17:20 +0900."
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Date: Wed, 28 Jun 2017 10:23:54 +0200
Message-ID: <4579.1498638234@localhost>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote:

> The patch got conflicted. This is a new version just rebased to
> the current master. Furtuer amendment will be taken later.

Can you please explain this part of make_append() ?

/* Currently async on partitioned tables is not available */
Assert(nasyncplans =3D=3D 0 || partitioned_rels =3D=3D NIL);

I don't think the output of Append plan is supposed to be ordered even if t=
he
underlying relation is partitioned. Besides ordering, is there any other
reason not to use the asynchronous execution?

And even if there was some, the planner should ensure that executor does not
fire the assertion statement above. The script attached shows an example how
to cause the assertion failure.

--=20
Antonin Houska
Cybertec Sch=C3=B6nig & Sch=C3=B6nig GmbH
Gr=C3=B6hrm=C3=BChlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de, http://www.cybertec.at


--=-=-=
Content-Type: text/plain
Content-Disposition: attachment; filename=async_append_test.sh

OPT_HOST="-h localhost"
USER=postgres

for x in $(psql $OPT_HOST -c "SELECT datname FROM pg_database WHERE datname ~ 'shard.*' " postgres -A -t)

do
	echo dropping $x
	dropdb $OPT_HOST $x
done;

createdb $OPT_HOST shard

psql $OPT_HOST -U $USER shard -c "
	CREATE EXTENSION postgres_fdw;
	CREATE TABLE orders(customer_id int, product_id int)
	       PARTITION BY LIST (customer_id);"
createdb $OPT_HOST shard_0
psql $OPT_HOST -U $USER shard_0 -c "
		CREATE TABLE orders_0 AS
		SELECT trunc(2 * random())::int AS customer_id,
		       trunc(100 * random())::int AS product_id
		FROM generate_series(1, 5000);
		ANALYZE;"
psql $OPT_HOST -U $USER shard -c "
		CREATE SERVER server_0 FOREIGN DATA WRAPPER postgres_fdw
			OPTIONS (host 'localhost', dbname 'shard_0', fetch_size '1000',
			use_remote_estimate 'true', fdw_tuple_cost '10');
		CREATE USER MAPPING FOR CURRENT_USER SERVER server_0 OPTIONS (user '$USER');
		IMPORT FOREIGN SCHEMA public FROM SERVER server_0 INTO public;
		ALTER TABLE orders ATTACH PARTITION orders_0 FOR VALUES IN (0, 1);"

createdb $OPT_HOST shard_1
psql $OPT_HOST -U $USER shard_1 -c "
		CREATE TABLE orders_1 AS
		SELECT trunc(2 * random())::int + 2 AS customer_id,
		       trunc(100 * random())::int + 2 AS product_id
		FROM generate_series(1, 5000);
		ANALYZE;"
psql $OPT_HOST -U $USER shard -c "
		CREATE SERVER server_1 FOREIGN DATA WRAPPER postgres_fdw
			OPTIONS (host 'localhost', dbname 'shard_1', fetch_size '1000',
			use_remote_estimate 'true', fdw_tuple_cost '10');
		CREATE USER MAPPING FOR CURRENT_USER SERVER server_1 OPTIONS (user '$USER');
		IMPORT FOREIGN SCHEMA public FROM SERVER server_1 INTO public;
		ALTER TABLE orders ATTACH PARTITION orders_1 FOR VALUES IN (2, 3);"


psql $OPT_HOST -U $USER shard -c "SELECT * FROM orders"

--=-=-=
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

--=-=-=--