public inbox for [email protected]  

help / color / mirror / Atom feed

From: Amit Langote <[email protected]>
To: Bruce Momjian <[email protected]>
To: David Rowley <[email protected]>
Cc: Justin Clift <[email protected]>
Cc: Jonathan S. Katz <[email protected]>
Cc: [email protected]
Subject: Re: PostgreSQL 12: Feature Highlights
Date: Tue, 14 May 2019 18:25:43 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<CAKJS1f-1=BoVkJaTnfb87nrVUFLprdc7smsBsF5MGyCXnNivzw@mail.gmail.com>
	<[email protected]>
	<CAKJS1f9=xUz5y=VDy6hYMVpSoej9+D2BminegmfqHwdWQfpQ9w@mail.gmail.com>
	<[email protected]>
	<CAKJS1f84HJj3qiDzpX9-iz_6AAdiX7khtgUf0UPVEmEd3YZ4hQ@mail.gmail.com>
	<[email protected]>

On 2019/05/14 11:59, Bruce Momjian wrote:
> On Mon, May 13, 2019 at 10:50:59PM +1200, David Rowley wrote:
>> On Mon, 13 May 2019 at 18:37, Amit Langote
>> <[email protected]> wrote:
>>> It's true that optimizer and executor can now handle larger number of
>>> partitions efficiently, but the improvements in this release will only be
>>> meaningful to workloads where partition pruning is crucial, so I don't see
>>> why mentioning "pruning" is so misleading.  Perhaps, it would be slightly
>>> misleading to not mention it, because readers might think that queries
>>> like this one:
>>>
>>>   select count(*) from partitioned_table;
>>>
>>> are now faster in v12, whereas AFAIK, they perform perform more or less
>>> the same as in v11.
>>
>> This is true, but whether partitions are pruned or not is only
>> relevant to one of the many items the headline feature is talking
>> about. I'm not sure how you'd briefly enough mention that fact without
>> going into detail about which features are which and which are
>> affected by partition pruning.
>>
>> I think these are the sorts of details that can be mentioned away from
>> the headline features, which is why I think lumping these all in one
>> in the main release notes is a bad idea as it's pretty hard to do that
>> when they're all lumped in as one item.
> 
> I think the point is that partition pruning and tuple _routing_ to the
> right partition is also improved.  I updated the release note items to
> say:
> 
> 	Tables with thousands of child partitions can now be processed
> 	efficiently.

Considering the quoted discussion here, maybe it's a good idea to note
that only the operations that need to touch a small number of partitions
are now processed efficiently, which covers both SELECT/UPDATE/DELETE that
benefit from improved pruning efficiency and INSERT that benefit from
improved tuple routing efficiency.  So, maybe:

	Tables with thousands of child partitions can now be processed
	efficiently by operations that only need to touch a small number
        of partitions.

That is, as I mentioned above, as opposed to queries that need to process
all partitions (such as, select count(*) from partitioned_table), which
don't perform any faster in v12 than in v11.  The percentage of users who
run such workloads on PostgreSQL may be much smaller today, but perhaps
it's not a good idea to mislead them into thinking that *everything* with
partitioned tables is now faster even with thousands of partitions.

Thanks,
Amit

view thread (63+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: PostgreSQL 12: Feature Highlights
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox