Re: [HACKERS] parallelize queries containing subplans

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: [HACKERS] parallelize queries containing subplans
Дата
Msg-id CAFiTN-tq_9wsofNNa_7a9atdCgOmKs60NHazAS7Z2AzOvEiK8A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] parallelize queries containing subplans  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [HACKERS] parallelize queries containing subplans  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
Re: [HACKERS] parallelize queries containing subplans  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
On Mon, Jan 16, 2017 at 9:13 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> After commit-ab1f0c8, this patch needs a rebase.  Attached find
> rebased version of the patch.
>
> Thanks to Kuntal for informing me offlist that this patch needs rebase.

In this patch, I have observed some changes while creating subplan for
CTE. So I have reviewed this from that perspective and also tried to
perform some test.

Here is my finding/ comments.

@@ -1213,6 +1216,7 @@ SS_process_ctes(PlannerInfo *root)   &splan->firstColCollation); splan->useHashTable = false;
splan->unknownEqFalse= false;
 
+ splan->parallel_safe = best_path->parallel_safe;

I noticed that if path for CTE is parallel safe then we are marking
CTE subplan as parallel safe, In particular, I don't have any problem
with that, but can you add some test case which can cover this path, I
mean to say where CTE subplan are pushed.

------------
I have tried to test the subplan with CTE below is my test.
create table t1(a int , b varchar);
create table t (n int, b varchar);

Query:
explain verbose select * from t where t.n not in (WITH RECURSIVE t(n) AS (   VALUES (1) UNION ALL   SELECT a+1 FROM t1
WHEREa < 100
 
)
SELECT sum(n) FROM t);

During debugging I found that subplan created for below part of the
query is parallel_unsafe, Is it a problem or there is some explanation
of why it's not parallel_safe,

(WITH RECURSIVE t(n) AS (   VALUES (1) UNION ALL   SELECT a+1 FROM t1 WHERE a < 100
)
SELECT sum(n) FROM t);
----------


-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Anastasia Lubennikova
Дата:
Сообщение: Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?