On Wed, May 23, 2018 at 02:06:15PM +1200, David Rowley wrote: > On 23 May 2018 at 13:18, Bruce Momjian <br...@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 <br...@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 +
