On 3/16/20 9:15 AM, Björn Lundin wrote:
16 mars 2020 kl. 16:46 skrev Adrian Klaver <adrian.klaver@xxxxxxxxxxx
<mailto:adrian.klaver@xxxxxxxxxxx>>:
On 3/16/20 3:03 AM, Björn Lundin wrote:
Yeah, it's hard to think of any explanation other than "the query
used a
corrupt index on startts to produce the ordering". But your \d doesn't
show any index on startts. So maybe there's more than one amarkets
table?
I realize that I have (basically) the same dataset on another machine.
Which brings me back to your first post where you had:
Timing is on.
AUTOCOMMIT off
psql (9.6.10)
Type "help" for help.
Then you said the database was:
version
------------------------------------------------------------------------------------------------
PostgreSQL 9.4.15 on x86_64-unknown-linux-gnu, compiled by gcc (Debian
4.9.2-10) 4.9.2, 64-bit
(1 rad)
Which seemed to be confirmed by:
bnl@ibm2:~$ psql
Tidtagning är på.
AUTOCOMMIT off
psql (9.6.15, server 9.4.15)
Skriv "help" för hjälp.
That leaves me wondering how you got to the output in the first post?
Ooh - terrible sorry.
The output from first post describing the database schema
Was actually from my production machine - a raspberry pi.
The pi hold a db on an usb-disk, which is pg_dump()ed every night and
imported to ibm2 history db (the bad one)
The schema is identical to the one with trouble - which is a history
database
Intended for testing
To be clear the RPI version of the database sorts correctly?
I did not realize that would matter when posting - did the post away
from home,
Yes, it would be have been nice to know at the outset there where
multiple instances involved.
I can reach the prod machine but not the history machine (ibm2) from
outside.
So - from the pi - first post
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
