Re: no partition pruning when partitioning using array type
От | Alvaro Herrera |
---|---|
Тема | Re: no partition pruning when partitioning using array type |
Дата | |
Msg-id | 20180710181857.anc6r7mzhufyqjhv@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: no partition pruning when partitioning using array type (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: no partition pruning when partitioning using array type
Re: no partition pruning when partitioning using array type |
Список | pgsql-hackers |
On 2018-May-08, Amit Langote wrote: > In HEAD, since we already fixed that case in e5dcbb88a15d [1] which is a > different piece of code anyway, the patch only serves to improve the > deparse output emitted by ruleutils.c for partition constraint expressions > where pseudo-type partition key is involved. The change can be seen in > the updated test output for create_table test. Actually, even in 11/master it also fixes this case: alvherre=# explain update p set a = a || a where a = '{1}'; QUERY PLAN ────────────────────────────────────────────────────────── Update on p (cost=0.00..54.03 rows=14 width=38) Update on p1 Update on p2 -> Seq Scan on p1 (cost=0.00..27.02 rows=7 width=38) Filter: (a = '{1}'::integer[]) -> Seq Scan on p2 (cost=0.00..27.02 rows=7 width=38) Filter: (a = '{1}'::integer[]) (7 filas) Because UPDATE uses the predtest.c prune code, not partprune. So it's not just some ruleutils beautification. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: