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
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 |