Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nAgA0-0007Ce-4j for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Jan 2022 22:44:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nAg9x-000302-S8 for pgsql-hackers@arkaria.postgresql.org; Thu, 20 Jan 2022 22:44:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nAg9x-0002zp-Cz for pgsql-hackers@lists.postgresql.org; Thu, 20 Jan 2022 22:44:01 +0000 Received: from mail-il1-x12e.google.com ([2607:f8b0:4864:20::12e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nAg9s-0002WJ-JB for pgsql-hackers@lists.postgresql.org; Thu, 20 Jan 2022 22:44:00 +0000 Received: by mail-il1-x12e.google.com with SMTP id i1so236910ils.5 for ; Thu, 20 Jan 2022 14:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=nTVGok/uWiucB16333NI3jHULMe3zX/Xrh9+DX2BPmM=; b=vZ1SOPypxgjxTzBlHAIZ+pChw6WmfsVRiy1kJVDEdusUT0WWqcN8fQ+sMiUg6y8CuH CGitKUd6jce/qE4vto3Hcy7Bt0zS3sPo7HoHpDm5c5m7O1PvkKde8B1I+0sARH0wcccZ hwYFRPtsO1nu8NfENuVy3y2rQLB61QR+U1OGhd+dDR03fcpcZCl5+P4DTrdgaIPLKUw7 tfvUWGTaJ7gCmr0BRpBj+ombUyRbY+8K03aK8OPJasI/65+FVXr7Gp0Imtxno6noD+Nj W7JPPK0wJiUh+9sKMOnVCgY188vXiacckD1qIKFtSJZKlE6HUOjwoANAeUhE4RLtM5S8 YgvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=nTVGok/uWiucB16333NI3jHULMe3zX/Xrh9+DX2BPmM=; b=B+JGp4QZOBdWKpa8z9YjO1s8gXCzp129UVMhl+GaNwwj82gbJ/sFT2vv/MobqcfBp4 mCWYtbYBmDolpT66IAHXkbGMRi7w8qfnF//pG/WspvjUEbeS9ec6QhZReWcgw99qRFwP E4dIaxqEwakeP6oWk46/TWYVDwZYMlNP/RVqeMQGyvJNAnKFCa3ygf0+3ccdBr8fjJBm 579uD+9sd45VFbuHkVcMyTYcHJc9bQnoBXaNunE5EPRrNIsWg4Tz8lh3rqHYu6E6MCsw M3rmYbvusTNacXbGk+a4iE6u7c9XqBMTH7TUO/VzmJZ+jRCP+XWktPUwcb4U32UOKUr+ CuwA== X-Gm-Message-State: AOAM533Rkv69GHU+ioplnm6oub+z/9ysCqa0uOIIzL6jhaLt9ak0+8b8 W69m3hbQG+cKwUvWcX71aBAdNg== X-Google-Smtp-Source: ABdhPJwFWw4Bgu+FvPmiiMVC8p34ZoiwTFmAKQg0SIiycAV+qDrl3JOaoqDwDRjCX0+CEKEkM3fQYw== X-Received: by 2002:a92:7d11:: with SMTP id y17mr646001ilc.64.1642718633525; Thu, 20 Jan 2022 14:43:53 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id s13sm1868499iln.15.2022.01.20.14.43.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jan 2022 14:43:53 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 78C3D80091D; Thu, 20 Jan 2022 16:43:52 -0600 (CST) Date: Thu, 20 Jan 2022 16:43:52 -0600 From: Justin Pryzby To: "Lugosi, Jim" Cc: pgsql-hackers@lists.postgresql.org Subject: Re: Poor performance PostgreSQL13/PostGIS 3.x Message-ID: <20220120224352.GK23027@telsasoft.com> References: <792d4b48d5b2404cb1a521b25536eb49@clackamas.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <792d4b48d5b2404cb1a521b25536eb49@clackamas.us> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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. Our 9.6 version was compiled from source and the new version (13) was installed using Yum. BTW, the new version is on a VM that has 16GB of memory, two cores, and 500 GB of disk. In addition, we are using MapServer as our mapping engine and OpenLayers as the client side interface. Once we switch over to the new version of PostgreSQL, the performance takes a big nose dive. We have being tweaking and tuning the database and it appears to be happy but the response times from mapfile 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 really sure 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 following query "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