Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1 - Mailing list pgsql-performance

From Gregory Stark
Subject Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1
Date
Msg-id 87abq4ytrp.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: partitioned table and ORDER BY indexed_field DESC LIMIT 1  ("Luke Lonergan" <LLonergan@greenplum.com>)
List pgsql-performance
"Luke Lonergan" <LLonergan@greenplum.com> writes:

> The approach we took was to recognize the ordering of child nodes and
> propagate that to the append in the special case of only one child (after
> CE). This is the most common use-case in 'partitioning', and so is an easy,
> high payoff low amount of code fix.

Ah yes, we should definitely try to prune singleton append nodes. On a lark I
had tried to do precisely that to see what would happen but ran into precisely
the problem you had to solve here with your pullup_vars function. That's one
of the functions which wasn't included in the original patch so I'll look at
the patch from the queue to see what's involved.

Actually currently it's not a common case because we can't eliminate the
parent partition. I have some ideas for how to deal with that but haven't
written them up yet.

In theory if we can preserve ordering across append nodes there's no good
reason to prune them. But generally I think simplifying the plan is good if
only to present simpler plans to the user.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

pgsql-performance by date:

Previous
From: Pablo Alcaraz
Date:
Subject: Re: Speed difference between select ... union select ... and select from partitioned_table
Next
From: Simon Riggs
Date:
Subject: Re: partitioned table and ORDER BY indexed_field DESCLIMIT 1