Re: BUG #10164: Inconsistent Order When Limit is Applied

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: sluggy(dot)fan(at)gmail(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #10164: Inconsistent Order When Limit is Applied
Date: 2014-04-28 23:02:03
Message-ID: 29989.1398726123@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

sluggy(dot)fan(at)gmail(dot)com writes:
> The documentation states that when the ordered fields all have the same
> value, that the order is implementation-dependent, but shouldn't that
> implementation be consistent no matter what the LIMIT is?

Uh, no. The code is entitled to return the rows containing lower(field1)
= 't' in any order, and there's no reason to think it will make the same
decisions with different LIMITs. (The technical reason for this is that
it's a heapsort with a bounded number of heap elements, so the exact
contents of the heap at the end of the input scan will vary depending on
your LIMIT, and heapsort isn't stable so the positions of equal-keyed
elements after sorting can vary.)

If you want a guaranteed ordering of the rows you'll need to specify
additional sort columns to break ties.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message 德哥 2014-04-28 23:18:48 Re: BUG #10155: BUG? Cann't remove new generated tuples after repeatable read transaction start.
Previous Message sluggy.fan 2014-04-28 19:23:20 BUG #10164: Inconsistent Order When Limit is Applied