Re: PostgreSQL 12: Feature Highlights
От | Amit Langote |
---|---|
Тема | Re: PostgreSQL 12: Feature Highlights |
Дата | |
Msg-id | b7954643-41ef-a174-479d-1f8d4834f40a@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: PostgreSQL 12: Feature Highlights (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: PostgreSQL 12: Feature Highlights
(Bruce Momjian <bruce@momjian.us>)
|
Список | pgsql-advocacy |
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 >> <Langote_Amit_f8@lab.ntt.co.jp> 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
В списке pgsql-advocacy по дате отправления: