tablesample with partitioned tables

Started by Amit Langotealmost 9 years ago3 messages
#1Amit Langote
Langote_Amit_f8@lab.ntt.co.jp
1 attachment(s)

Attached patch fixes an oversight that tablesample cannot be used with
partitioned tables:

create table p (a int) partition by list (a);
select * from p tablesample bernoulli (50);
ERROR: TABLESAMPLE clause can only be applied to tables and materialized
views

Thanks,
Amit

Attachments:

0001-Partitioned-tables-support-tablesample.patchtext/x-diff; name=0001-Partitioned-tables-support-tablesample.patchDownload
From d9c412ea14b005b4c6013026c6c62eab97727c3c Mon Sep 17 00:00:00 2001
From: amit <amitlangote09@gmail.com>
Date: Wed, 22 Feb 2017 16:27:35 +0900
Subject: [PATCH] Partitioned tables support tablesample

---
 src/backend/parser/parse_clause.c         |  3 ++-
 src/test/regress/expected/tablesample.out | 18 ++++++++++++++++++
 src/test/regress/sql/tablesample.sql      |  8 ++++++++
 3 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/src/backend/parser/parse_clause.c b/src/backend/parser/parse_clause.c
index fecc1d6598..b5eae56006 100644
--- a/src/backend/parser/parse_clause.c
+++ b/src/backend/parser/parse_clause.c
@@ -907,7 +907,8 @@ transformFromClauseItem(ParseState *pstate, Node *n,
 		rte = rt_fetch(rtr->rtindex, pstate->p_rtable);
 		/* We only support this on plain relations and matviews */
 		if (rte->relkind != RELKIND_RELATION &&
-			rte->relkind != RELKIND_MATVIEW)
+			rte->relkind != RELKIND_MATVIEW &&
+			rte->relkind != RELKIND_PARTITIONED_TABLE)
 			ereport(ERROR,
 					(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
 					 errmsg("TABLESAMPLE clause can only be applied to tables and materialized views"),
diff --git a/src/test/regress/expected/tablesample.out b/src/test/regress/expected/tablesample.out
index 7e91b958ae..b18e420e9b 100644
--- a/src/test/regress/expected/tablesample.out
+++ b/src/test/regress/expected/tablesample.out
@@ -313,3 +313,21 @@ SELECT q.* FROM (SELECT * FROM test_tablesample) as q TABLESAMPLE BERNOULLI (5);
 ERROR:  syntax error at or near "TABLESAMPLE"
 LINE 1: ...CT q.* FROM (SELECT * FROM test_tablesample) as q TABLESAMPL...
                                                              ^
+-- check partitioned tables support tablesample
+create table parted_sample (a int) partition by list (a);
+create table parted_sample_1 partition of parted_sample for values in (1);
+create table parted_sample_2 partition of parted_sample for values in (2);
+explain (costs off)
+  select * from parted_sample tablesample bernoulli (100);
+                QUERY PLAN                 
+-------------------------------------------
+ Append
+   ->  Sample Scan on parted_sample
+         Sampling: bernoulli ('100'::real)
+   ->  Sample Scan on parted_sample_1
+         Sampling: bernoulli ('100'::real)
+   ->  Sample Scan on parted_sample_2
+         Sampling: bernoulli ('100'::real)
+(7 rows)
+
+drop table parted_sample, parted_sample_1, parted_sample_2;
diff --git a/src/test/regress/sql/tablesample.sql b/src/test/regress/sql/tablesample.sql
index eec9793496..c39fe4b750 100644
--- a/src/test/regress/sql/tablesample.sql
+++ b/src/test/regress/sql/tablesample.sql
@@ -100,3 +100,11 @@ WITH query_select AS (SELECT * FROM test_tablesample)
 SELECT * FROM query_select TABLESAMPLE BERNOULLI (5.5) REPEATABLE (1);
 
 SELECT q.* FROM (SELECT * FROM test_tablesample) as q TABLESAMPLE BERNOULLI (5);
+
+-- check partitioned tables support tablesample
+create table parted_sample (a int) partition by list (a);
+create table parted_sample_1 partition of parted_sample for values in (1);
+create table parted_sample_2 partition of parted_sample for values in (2);
+explain (costs off)
+  select * from parted_sample tablesample bernoulli (100);
+drop table parted_sample, parted_sample_1, parted_sample_2;
-- 
2.11.0

#2David Fetter
david@fetter.org
In reply to: Amit Langote (#1)
Re: tablesample with partitioned tables

On Wed, Feb 22, 2017 at 04:51:46PM +0900, Amit Langote wrote:

Attached patch fixes an oversight that tablesample cannot be used with
partitioned tables:

create table p (a int) partition by list (a);
select * from p tablesample bernoulli (50);
ERROR: TABLESAMPLE clause can only be applied to tables and materialized
views

Thanks!

Should the error message change somehow to reflect that partitioned
tables are included? Is complete transparency of partitioned tables
the goal, and reasonable in this context?

Also, is there a good reason apart from tuits not to expand
TABLESAMPLE to the rest of our SQL-visible relation structures? I'm
guessing this could have something to do with the volatility they
might have, whether in views that call volatile functions or in
foreign tables that might not make the right guarantees...

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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

#3Amit Langote
Langote_Amit_f8@lab.ntt.co.jp
In reply to: David Fetter (#2)
Re: tablesample with partitioned tables

On 2017/02/23 0:54, David Fetter wrote:

On Wed, Feb 22, 2017 at 04:51:46PM +0900, Amit Langote wrote:

Attached patch fixes an oversight that tablesample cannot be used with
partitioned tables:

create table p (a int) partition by list (a);
select * from p tablesample bernoulli (50);
ERROR: TABLESAMPLE clause can only be applied to tables and materialized
views

Thanks!

Should the error message change somehow to reflect that partitioned
tables are included? Is complete transparency of partitioned tables
the goal, and reasonable in this context?

We avoid mentioning partitioned tables separately during most of the
errors caused by relkind checks. I mentioned recently [1]/messages/by-id/854ad246-4dfa-5c68-19ad-867b6800f313@lab.ntt.co.jp that in most of
these sites such as this one, a table's being partitioned is not significant.

Also, is there a good reason apart from tuits not to expand
TABLESAMPLE to the rest of our SQL-visible relation structures? I'm
guessing this could have something to do with the volatility they
might have, whether in views that call volatile functions or in
foreign tables that might not make the right guarantees...

I wouldn't be able to say much about that, but I found an email from the
original discussion that occurred around development of this feature that
posed the same question. There might be some answers there.

[1]: /messages/by-id/854ad246-4dfa-5c68-19ad-867b6800f313@lab.ntt.co.jp
/messages/by-id/854ad246-4dfa-5c68-19ad-867b6800f313@lab.ntt.co.jp
[2]: /messages/by-id/5526D369.1070905@gmx.net

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