Extend more usecase for planning time partition pruning and init partition pruning.

From: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Extend more usecase for planning time partition pruning and init partition pruning.
Date: 2021-01-24 10:34:26
Message-ID: CAKU4AWq4NLxu5JF9+d=o=A636-=eFNFmPx+kJ44ezTm=ikZ73w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi:

I recently found a use case like this. SELECT * FROM p, q WHERE p.partkey
=
q.colx AND (q.colx = $1 OR q.colx = $2); Then we can't do either planning
time
partition prune or init partition prune. Even though we have run-time
partition pruning work at last, it is too late in some cases since we have
to init all the plan nodes in advance. In my case, there are 10+
partitioned relation in one query and the execution time is short, so the
init plan a lot of plan nodes cares a lot.

The attached patches fix this issue. It just get the "p.partkey = q.colx"
case in root->eq_classes or rel->joinlist (outer join), and then check if
there
is some baserestrictinfo in another relation which can be used for partition
pruning. To make the things easier, both partkey and colx must be Var
expression in implementation.

- v1-0001-Make-some-static-functions-as-extern-and-extend-C.patch

Just some existing refactoring and extending ChangeVarNodes to be able
to change var->attno.

- v1-0002-Build-some-implied-pruning-quals-to-extend-the-us.patch

Do the real job.

Thought?

--
Best Regards
Andy Fan (https://www.aliyun.com/)

Attachment Content-Type Size
v1-0001-Make-some-static-functions-as-extern-and-extend-C.patch application/octet-stream 5.9 KB
v1-0002-Build-some-implied-pruning-quals-to-extend-the-us.patch application/octet-stream 40.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2021-01-24 11:00:16 Re: [HACKERS] GSoC 2017: Foreign Key Arrays
Previous Message Andy Fan 2021-01-24 10:26:33 Re: [PATCH] Keeps tracking the uniqueness with UniqueKey