Re: Poor performance PostgreSQL13/PostGIS 3.x - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: Poor performance PostgreSQL13/PostGIS 3.x
Date
Msg-id 20220120224352.GK23027@telsasoft.com
Whole thread Raw
In response to Poor performance PostgreSQL13/PostGIS 3.x  ("Lugosi, Jim" <JimLug@clackamas.us>)
List pgsql-hackers
On Thu, Jan 20, 2022 at 10:31:15PM +0000, Lugosi, Jim wrote:
> We are struggling to figure out what is going on.  We are migrating from PostgreSQL 9.6 to PostgreSQL 13 w/ PostGIS.
Our9.6 version was compiled from source and the new version (13) was installed using Yum.  BTW, the new version is on a
VMthat has 16GB of memory, two cores, and 500 GB of disk.  In addition, we are using MapServer as our mapping engine
andOpenLayers as the client side interface.  Once we switch over to the new version of PostgreSQL, the performance
takesa big nose dive.  We have being tweaking and tuning the database and it appears to be happy but the response times
frommapfile requests are 3 -7 seconds.  Previously, the response time was below a second.
 
> 
> Another point is that we populated the new database from the old (9.6), using pg_dump.  Could this be causing issues?
Should we load the data from scratch?  We use ogr2ogr (GDAL) to help assist with loading of spatial data.  Anyway, not
reallysure what the problem is.
 
> 
> Lastly, why am I seeing so many requests as to the PostGIS version.  It appears that every map request sends the
followingquery "SELECT PostGIS_Version();", which in turn takes up a connection.
 

This list is for postgres development and bug reports.

I suggest to post here, instead:
https://www.postgresql.org/list/pgsql-performance/

Here's a list of needed info:
https://wiki.postgresql.org/wiki/Slow_Query_Questions

It's important to include the slow query itself.

-- 
Justin



pgsql-hackers by date:

Previous
From: "Lugosi, Jim"
Date:
Subject: Poor performance PostgreSQL13/PostGIS 3.x
Next
From: Peter Geoghegan
Date:
Subject: Re: autovacuum prioritization