Re: Postgres 11 release notes

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgres 11 release notes
Date: 2018-05-21 07:34:18
Message-ID: CAKJS1f9LZW2cc0Rw0UVMg0xS88Q84yJKYLD+w36aM493LowFXQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

On 19 May 2018 at 03:58, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> I wonder what you think about including this little performance item:
>
> https://www.postgresql.org/message-id/E1eotSQ-0005V0-LV@gemulon.postgresql.org
>
> especially considering the part of the commit message which states
>
> ...Still, testing shows
> that this makes single-row inserts significantly faster on a table
> with many partitions without harming the bulk-insert case.
>
> I recall seeing those inserts being as much as 2x faster as partition
> count grows beyond hundreds. One might argue that we should think
> about publicizing this only after we've dealt with the
> lock-all-partitions issue that's also mentioned in the commit message
> which is still a significant portion of the time spent and I'm totally
> fine with that.

While I do think that was a good change, I do think there's much still
left to do to speed up usage of partitioned tables with many
partitions.

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
shouting anything from the rooftops about the work done in this area
for PG11, since it's still got a long way to go still before the
feature is usable with higher numbers of partitions. I do think your
change was a good one to make, but I just don't want users to think
that we're done here when we all know that much work remains.

If we're going to add an item in the release notes about this then I
wouldn't object, providing it could be done in a way that indicates
we've not finished here yet, but if that's the case then maybe it's
better to say nothing at all.

--
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 Craig Ringer 2018-05-21 07:50:28 Re: Postgres, fsync, and OSs (specifically linux)
Previous Message Craig Ringer 2018-05-21 07:32:01 Message on end of cascading physical replica timeline is unhelpful

Browse pgsql-www by date

  From Date Subject
Next Message Haribabu Kommi 2018-05-21 08:28:36 Re: Postgres 11 release notes
Previous Message Michael Paquier 2018-05-19 12:35:57 Re: SCRAM with channel binding downgrade attack