Re: Performance regression with PostgreSQL 11 and partitioning

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Thomas Reiss <thomas(dot)reiss(at)dalibo(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance regression with PostgreSQL 11 and partitioning
Date: 2018-06-05 00:20:14
Message-ID: CAKJS1f9pioTRX84Tf3QTHxPXWvN4odtbTE_z0g3On+vgN+7U_w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5 June 2018 at 01:35, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
> I was wondering if we can get rid of append_rel_list altogether. In
> your patch, you have saved AppendRelInfos by child_relid. So all the
> slots indexed by parent relid are empty. We could place AppendRelInfos
> by parent relid. Thus a given AppendRelInfo would be places at two
> places, one at the index of child relid and second at the index
> pointed by parent relid. That's fine even in case of multilevel
> inheritance since an intermediate parent has two relids one as a
> parent and other as a child.
>
> One problem with that we do not know how long the array would be to
> start with. But we could keep on repallocing the array to increase its
> size.

To be honest, the patch was meant as a discussion topic for ways to
improve the reported regression in PG11. The patch was put together
fairly quickly.

I've not really considered what happens in the case where an inherited
table has multiple parents. The patch happens to pass regression
tests, but I've not checked to see if the existing tests create any
tables this way.

Perhaps it's okay to change things this way for just partitioned
tables and leave inheritance hierarchies alone.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2018-06-05 00:36:18 Re: Code of Conduct plan
Previous Message Tom Lane 2018-06-05 00:18:24 Re: Code of Conduct plan