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

From David Rowley
Subject Re: How to make partitioning scale better for larger numbers of partitions
Date
Msg-id CAKJS1f9tqFC=+uVkPSmF2gWQ-T02vZE2vKhjp0Sn-Q7WG4AnNQ@mail.gmail.com
Whole thread Raw
In response to RE: How to make partitioning scale better for larger numbers ofpartitions  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
On 13 July 2018 at 18:53, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> By the way, what do you think is the "ideal and should-be-feasible" goal and the "realistic" goal we can reach in the
nearfuture (e.g. PG 12)?  Say,
 

Depends. Patched don't move that fast without review and nothing gets
committed without a committer.

> * Planning and execution time is O(log n), where n is the number of partitions
> * Planning time is O(log n), execution time is O(1)
> * Planning and execution time is O(1), where n is the number of partitions

It's going to depend on how many partitions are pruned. We still need
to generate paths for all non-pruned partitions which is going to be
slow when there are many partitions.

I think we can get pretty close to the non-partitioned planning
performance with SELECT/UPDATE/DELETE when all but 1 partition
survives pruning. There are always going to be some additional
overhead we can't get rid of, but hopefully, those will be small.

Please feel free to review what I have in the July 'fest.

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


pgsql-hackers by date:

Previous
From: Chris Travers
Date:
Subject: Re: How can we submit code patches that implement our (pending) patents?
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: How to make partitioning scale better for larger numbers ofpartitions