Received: from malur.postgresql.org ([2a02:16a8:dc51::56])
	by arkaria.postgresql.org with esmtps
 (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.89)
	(envelope-from <pgsql-admin-owner+archive@lists.postgresql.org>)
	id 1g05VJ-0006pP-Te
	for pgsql-admin@arkaria.postgresql.org; Wed, 12 Sep 2018 13:48:26 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-admin-owner+archive@lists.postgresql.org>)
	id 1g05VI-0002eW-9i
	for pgsql-admin@arkaria.postgresql.org; Wed, 12 Sep 2018 13:48:24 +0000
Received: from makus.postgresql.org ([2001:4800:1501:1::229])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.89)
	(envelope-from <mirrorx@gmail.com>)
	id 1g05FI-00017u-Dt
	for pgsql-admin@lists.postgresql.org; Wed, 12 Sep 2018 13:31:52 +0000
Received: from n3.nabble.com ([162.255.23.22])
	by makus.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <mirrorx@gmail.com>)
	id 1g05FF-0004jY-O7
	for pgsql-admin@postgresql.org; Wed, 12 Sep 2018 13:31:51 +0000
Received: from n3.nabble.com (localhost [127.0.0.1])
	by n3.nabble.com (Postfix) with ESMTP id 737FEF1AD6FD
	for <pgsql-admin@postgresql.org>; Wed, 12 Sep 2018 06:31:49 -0700 (MST)
Date: Wed, 12 Sep 2018 06:31:49 -0700 (MST)
From: MirrorX <mirrorx@gmail.com>
To: pgsql-admin@postgresql.org
Message-ID: <1536759109470-0.post@n3.nabble.com>
Subject: vacuum and query plans?
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Id: <pgsql-admin.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-admin@lists.postgresql.org>
List-Owner: <mailto:pgsql-admin-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-admin>
Precedence: bulk

hello,
a bit of a theoretical question if you dont mind..
i ve seen lately more and more occurences of queries having huge planning
times (>500ms) while their execution time is very low (<10ms). at that
point, if a vacuum is executed on the table involved (without analyze) then
the planning time goes back to 'normal'. could someone elaborate on the
connection between planning time and what vacuum does? i am asking bc i
would have thought that an analyze would have resolved the issue (with
increased sampling for example) but it didnt. only vacuum does resolve it.

thank you in advance


(the version is 9.4.x)



--
Sent from: http://www.postgresql-archive.org/PostgreSQL-admin-f2076596.html