PostgreSQL 9.6.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9), 64-bit
Connecting with pgAdmin 4.
The result set looks like some form of merge sort was being performed, but the system decided to skip the last few merge iterations.
You're correct, the statement I've sent does not reproduce the issue. The actual query I'm using is much longer, but I've managed to reproduce the issue with "select * from tbl_recognition_logging where action='identify' order by created". 'action' is a text field and I see that pgAdmin 4 highlights it like a reserved word.
Regards,
Rick Gentry
-----------------
Zenus, Inc.
On Tue, May 15, 2018 at 1:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Rick Gentry <rick.gentry@zenus-biometrics.com> writes: > I have a table that I'm using to log results from my system. It has a > field "created timestamp default current_timestamp."
> Running the query "select * from tbl_log order by created asc;" works as > expected.
> Running the query "select * from tbl_log order by created;" returns sorted > chunks of 2000 records.
It's quite hard to believe that the ASC annotation affects anything; it's easily proven that PG's parser creates identical parsetrees for those two statements. I have to guess that there is some other effect involved here.
To start with, what PG version is this, what do you mean exactly by "sorted chunks", and what client-side code are you using? Can you create a self-contained example of the misbehavior?
