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 > order? 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. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers