On Wed, May 23, 2018 at 02:06:15PM +1200, David Rowley wrote:
> On 23 May 2018 at 13:18, Bruce Momjian <bruce@momjian.us> wrote:
> > On Mon, May 21, 2018 at 07:34:18PM +1200, David Rowley wrote:
> >> I've been working a bit in this area over the past few weeks and with
> >> PG11 I measured a single INSERT into a 10k RANGE partitioned table at
> >> just 84 tps (!), while inserting the same row into a non-partitioned
> >> table was about 11.1k tps. I have patches locally that take this up to
> >> ~9.8k tps, which I'll submit for PG12. I'm unsure if we should be
> >
> > Yikes! I think the question is whether we need to _remove_ the item I
> > just posted that is already in the release notes:
> >
> > Allow faster partition elimination during query processing (Amit
> > Langote, David Rowley, Dilip Kumar)
> >
> > This speeds access to partitioned tables with many partitions.
>
> Well, partition elimination/pruning and tuple routing are not the same
> thing. Pruning saves us scanning partitions that can't contain
> matching tuples, whereas routing finds a home for a specific tuple.
I just suspected they would use the same algorithm.
> Amit's work to improve partition elimination certainly is much faster
> than constraint exclusion. It's not the last thing we'll ever do to
> speed up the planning of queries for partitioned tables but it is a
> very good start, and without it, run-time pruning would not be
> possible.
>
> I'd say the release notes in this regard don't claim anything that's
> untrue. They look fine to me. Thanks for working on them!
OK.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
