Re: BUG #5543: Poor performance - Index scan backwards not used for order by desc with partitioned tables
От | Robert Haas |
---|---|
Тема | Re: BUG #5543: Poor performance - Index scan backwards not used for order by desc with partitioned tables |
Дата | |
Msg-id | AANLkTimX=GkWjbzJ38a6ESe9ZRoqtMWW3KxzYJzwvcHS@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #5543: Poor performance - Index scan backwards not used for order by desc with partitioned tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Tue, Jul 27, 2010 at 7:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> Does it help if you put a CHECK (false) constraint on the parent table? > > It won't --- it'll still result in an append plan even if there's only > one surviving child. > > This is one of many things that seem to me to not make sense to tackle > until we have an explicit notion of partitioning. =A0Having the planner > try to prove from individual constraints that it could get a correctly > sorted Append result without an explicit sort step would be hugely > expensive, and complicated --- imagine even trying to pick out the > relevant indexes without any infrastructure to help identify them. > With a partitioned structure we could understand that a-priori. Hmm, I thought we had something that made it behave more like the non-partitioned case when there is only one surviving partition. But I agree that, perhaps apart from that special case, there's not much hope of improving this until we have more infrastructure. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-bugs по дате отправления: