Re: pg12 release notes
От | David Rowley |
---|---|
Тема | Re: pg12 release notes |
Дата | |
Msg-id | CAKJS1f8R6DC45bauzeGF-QMaQ90B_NFSJB9mvVOuhKVDkajehg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg12 release notes (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: pg12 release notes
|
Список | pgsql-hackers |
On Fri, 10 May 2019 at 16:57, Justin Pryzby <pryzby@telsasoft.com> wrote: > > 8edd0e7 Suppress Append and MergeAppend plan nodes that have a single child. You could say that I'm biased, but I think this should get a mention. It's not just a matter of tidying up the plan by getting rid of nodes that are not requires, it allows plan shapes that were not possible before, for example, a parallel index scan on the index of a partition and the ability to not needlessly include a Materialize node in a Merge Join or Nested Loop Join to a partitioned table, when only 1 partition survives pruning. I'd say wording along the lines of: * Allow the optimizer to no longer generate plans containing a single sub-node Append/MergeAppend node. This allows more plan types to be considered. [...] > > Perform: > > 959d00e Use Append rather than MergeAppend for scanning ordered partitions. I also think this is worth a mention. The speedup can be quite large when the query involves a LIMIT clause, and I think it will apply fairly often. Most of the times I've seen partitioned table the wild they were RANGE partitioned by a timestamp, or at least they were inheritance based tables partitioned by timestamp that could one day be changed to a RANGE partitioned table. I'd say something like: * Allow the optimizer to exploit the ordering of RANGE and LIST partitioned tables when generating paths for partitioned tables. This saves the optimizer from using MergeAppend node to scan a partitioned table in order when an Append node will do. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: