Seems to be a replicable issue in PostGis - ticket raised at their end,
so I'll wait for a resolution of the root cause.
Thanks for your help/thoughts.
Rgds
Bill
On 3/12/2016 2:41 AM, Daniel Blanch Bataller wrote:
ANALYZE takes samples at random, so statistics might be different even
wit
ANALYZE takes samples at random, so statistics might be different even with
same postgresql version:
https://www.postgresql.org/docs/current/static/sql-analyze.html
For large tables, ANALYZE takes a random sample of the table contents, rather
than examining every row. This allows even very larg
Thanks Tom.
First, this wasn't a migration but new db loaded from scratch (if that
matters).
As per the end of the original post "I have vacuum analysed both
tables". I assume this is what you meant?
My gut feel was that it isn't a postgis issue since the third example I
gave uses the ind
Bill Measday writes:
> Substantial different index use between 9.5 and 9.6
Maybe you missed an ANALYZE after migrating? The plan difference
seems to be due to a vast difference in rowcount estimate for the
m_elevations condition:
> -> Bitmap Heap Scan on m_elevations e
> (cost=282802.21
Substantial different index use between 9.5 and 9.6
Postgres versions 9.5 and 9.6 running on Windows Server 2012. Installed
using EnterpriseDB. Both instances are on the same server,
postgresql.conf for both are the same except max_locks_per_transaction =
200 in 9.6 (caused insertion errors oth
