Re: BUG #5543: Poor performance - Index scan backwards not used for order by desc with partitioned tables

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ranga Gopalan <ranga_gopalan(at)hotmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5543: Poor performance - Index scan backwards not used for order by desc with partitioned tables
Date: 2010-07-27 23:46:44
Message-ID: AANLkTimX=GkWjbzJ38a6ESe9ZRoqtMWW3KxzYJzwvcHS@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Jul 27, 2010 at 7:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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.  Having 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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message depstein 2010-07-28 13:50:48 Re: pg_upgrade issues
Previous Message Tom Lane 2010-07-27 23:27:42 Re: BUG #5543: Poor performance - Index scan backwards not used for order by desc with partitioned tables