Re: How to make partitioning scale better for larger numbers of partitions - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: How to make partitioning scale better for larger numbers of partitions
Date
Msg-id CAFjFpRd4hDifN=MZSxsu=6Y0ANZzjZLNVMtEp4mor4pk5a3_kQ@mail.gmail.com
Whole thread Raw
In response to RE: How to make partitioning scale better for larger numbers ofpartitions  ("Kato, Sho" <kato-sho@jp.fujitsu.com>)
Responses Re: How to make partitioning scale better for larger numbers ofpartitions  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
On Fri, Jul 13, 2018 at 9:23 AM, Kato, Sho <kato-sho@jp.fujitsu.com> wrote:
>>I wondered if you compared to PG10 or to inheritence-partitioning (parent with relkind='r' and either trigger or rule
or>INSERT/UPDATE directly into child) ?
 
>
> Thank you for your reply.
>
> I compared to PG11beta2 with non-partitioned table.
>
> Non-partitioned table has 1100 records in one table.
> Partitioned table has one record on each leaf partitions.
>

I don't think partitioning should be employed this way even for the
sake of comparison. Depending upon the size of each tuple, 1100 tuples
are inserted into a single table, they will probably occupy few
hundred pages. In a partitioned table with one tuple per partition
they will occupy 1100 pages at least. There is other space, locking
overheads to maintain 1100 tables. I think the right way to compare is
to have really large that which really requires 1100 partitions and
then compare performance by putting that data in 1100 partitions and
in an unpartitioned table. Even with that kind of data, you will see
some difference in performance, but that won't be as dramatic as you
report.

I might be missing something though.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


pgsql-hackers by date:

Previous
From: Jerry Jelinek
Date:
Subject: Re: patch to allow disable of WAL recycling
Next
From: Ashutosh Bapat
Date:
Subject: Re: partition pruning doesn't work with IS NULL clause in multikeyrange partition case