On 3/16/20 9:15 AM, Björn Lundin wrote:
>
>
>> 16 mars 2020 kl. 16:46 skrev Adrian Klaver <adrian.klaver@aklaver.com
>> <mailto:adrian.klaver@aklaver.com>>:
>>
>> 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@aklaver.com