On Fri, Sep 2, 2016 at 10:31 AM, Andres Freund <and...@anarazel.de> wrote:
> On 2016-09-02 09:41:28 -0500, Kevin Grittner wrote:
>> On Fri, Sep 2, 2016 at 9:25 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> > Andres Freund <and...@anarazel.de> writes:
>> >> Oh, and we've previously re-added that based on
>> >> complaints. C.f. d543170f2fdd6d9845aaf91dc0f6be7a2bf0d9e7 (and others
>> >> IIRC).
>> > That one wasn't about row order per se, but I agree that people *will*
>> > bitch if we change the behavior, especially if we don't provide a way
>> > to fix it.
>> They might also bitch if you add any overhead to put rows in a
>> specific order when they subsequently sort the rows into some
>> different order.
> Huh? It's just the order the SRFs are returning rows. If they
> subsequently ORDER, there's no issue. And that doesn't have a
> performance impact afaict.
If it has no significant performance impact to maintain the
historical order, then I have no problem with doing so. If you
burn resources putting them into historical order, that is going to
be completely wasted effort in some queries. THAT is what I would
object to. I'm certainly not arguing that we have any reason to go
out of our way to change the order.
>> You might even destroy an order that would have
>> allowed a sort step to be skipped, so you would pay twice -- once
>> to put them into some "implied" order and then to sort them back
>> into the order they would have had without that extra effort.
> So you're arguing that you can't rely on order, but that users rely on
No. I'm arguing that we track the order coming out of different
nodes during planning, and sometimes take advantage of it to avoid
a sort which would otherwise be required.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: