Re: speeding up planning with partitions

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
Cc: "Imai, Yoshikazu" <imai(dot)yoshikazu(at)jp(dot)fujitsu(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: speeding up planning with partitions
Date: 2019-01-28 04:18:02
Message-ID: CAKJS1f-THx93QgN2x8zdb6JJsgV6ntfghyUq1NTz5UNJWCVNvw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

On Sat, 12 Jan 2019 at 02:00, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>
> On 2019/01/09 9:09, David Rowley wrote:
> > postgres=# update parent set c = c where a = 333;
> > server closed the connection unexpectedly
> > This probably means the server terminated abnormally
> > before or while processing the request.
> >
> > I didn't look into what's causing the crash.
>
> I tried your example, but it didn't crash for me:
>
> explain update parent set c = c where a = 333;
> QUERY PLAN
> ────────────────────────────────────────────────────
> Update on parent (cost=0.00..0.00 rows=0 width=0)
> -> Result (cost=0.00..0.00 rows=0 width=54)
> One-Time Filter: false
> (3 rows)

I had a closer look. The crash is due to
set_inherit_target_rel_sizes() forgetting to set has_live_children to
false. This results in the relation not properly being set to a dummy
rel and the code then making a modify table node without any subnodes.
That crashes due to getTargetResultRelInfo() returning NULL due to
rootResultRelInfo and resultRelInfo both being NULL.

The attached fixes it. If you were not seeing the crash then
has_live_children must have been zero/false by chance during your
test.

A simple case of:

create table listp (a int, b int) partition by list(a);
create table listp1 partition of listp for values in(1);
update listp set b = b + 1 where a = 42;

was crashing for me.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
v17_fixup.diff application/octet-stream 527 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2019-01-28 04:31:43 Re: Protect syscache from bloating with negative cache entries
Previous Message Amit Kapila 2019-01-28 04:17:00 Re: pgsql: Avoid creation of the free space map for small heap relations.