Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ebzQj-0005lO-J3 for pgsql-performance@arkaria.postgresql.org; Thu, 18 Jan 2018 01:55:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ebzQi-0004NK-C1 for pgsql-performance@arkaria.postgresql.org; Thu, 18 Jan 2018 01:55:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ebzQi-0004NA-0e for pgsql-performance@lists.postgresql.org; Thu, 18 Jan 2018 01:55:48 +0000 Received: from mail-pg0-x242.google.com ([2607:f8b0:400e:c05::242]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ebzQa-0006lT-J8 for pgsql-performance@postgresql.org; Thu, 18 Jan 2018 01:55:47 +0000 Received: by mail-pg0-x242.google.com with SMTP id m20so12629714pgc.11 for ; Wed, 17 Jan 2018 17:55:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=FdRTCjGrL8G80fbRfI2gOjw0hWp17LCjDF1eJt+HroE=; b=KSRbDvMDMzPLnWcabftZLwe40SVTZ4w6jT7u5vPRcW7mxvbjoL+P9P+MXY1lvH+9cn HuENF210jX2r90loCWWfNCyUeOogVbrOwslkX3Qq2DvQMh6h9jVi/QQdUIyC4WJgNS3k EP8MX8aqxLww0fWHI3BI1ljZa/512gFLsbIvETTRm90A/yTFmDmHyYYsMqvFdTjOD5Zc EmfZwVqqtI6eqKVONEgbBzU/8z0QtDtkg3T9vpHVs0kr19UuLzWABgQPQgpOLzleBSra u+avqXbMwHU0toxEYOWGNKhIuDsIVacGy8C4tDh9iA7O2tAVjEe5XRSs41k3cnwvTXbX ooLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=FdRTCjGrL8G80fbRfI2gOjw0hWp17LCjDF1eJt+HroE=; b=T9XFjmmcp/UOJjT0Va9WZYKCFH0aqnobU4DJ4fAccuX8/C4lC0ne2qQfV3EzEA+5Rk uhVfO2DIeQnzEv92iQootlHxH+nf/jn30IJEf7OtJh+NSW9Kt9Fo3pBi3ypkpvS8K84F 4CI9gXuLy9Yq0fg4R7EZXsUjnjjk0vdgLHMgJIno56Fkk1o/IiMmjHmRhCjeYlrz3SZi 433DxEDyhMEuong36L2apiUOlVHJVr9n3lugo3s7gx4wB56Wr1tqybNXOJj5m7ZsQ6Z+ ci/0fl2TpVXiBEz/JIUopA9TyRlZEK+E/2EuQlRtFNvD5jDYs7QaJJ1xyS4RU6I7BH2H J3hQ== X-Gm-Message-State: AKwxytcBNQjILqbjbfqJyflCTgnPE415Ea/OLzk1Kuh5b7gdJewl0cSN CUNJlNpm/vZM2AazGRFieHhcMA== X-Google-Smtp-Source: ACJfBouOlzyXZUkTSWfL2rZCxpeB5gsuZHV8mt4w5XSuY/PYQTrvehV/caT2PjiET65efp9u8+YMRQ== X-Received: by 10.98.211.21 with SMTP id q21mr27713015pfg.89.1516240538273; Wed, 17 Jan 2018 17:55:38 -0800 (PST) Received: from paquier.xyz (c137162.net61215.cablenet.ne.jp. [61.215.137.162]) by smtp.gmail.com with ESMTPSA id i2sm9420294pgn.45.2018.01.17.17.55.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jan 2018 17:55:36 -0800 (PST) Date: Thu, 18 Jan 2018 10:55:32 +0900 From: Michael Paquier To: Jeff Janes Cc: Nandakumar M , "pgsql-performa." Subject: Re: Query is slow when run for first time; subsequent execution is fast Message-ID: <20180118015532.GE29962@paquier.xyz> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="N1GIdlSm9i+YlY4t" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --N1GIdlSm9i+YlY4t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 16, 2018 at 09:18:25PM -0800, Jeff Janes wrote: > Oh. I've not seen that before. But then again I don't often restart my > server and then immediately run very large queries with a stringent time > deadline. >=20 > You can try pg_prewarm, on pg_statistic table and its index. But I'd > probably just put an entry in my db startup script to run this query > immediately after startng the server, and let the query warm the cache > itself. >=20 > Why do you restart your database often enough for this to be an issue? Another thing that you could use here is pg_buffercache which offers a way to look at the Postgres shared buffer contents in real-time: https://www.postgresql.org/docs/current/static/pgbuffercache.html As Jeff says, pg_prewarm is a good tool for such cases to avoid any kind of warmup period when a server starts.. -- Michael --N1GIdlSm9i+YlY4t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlpf/pQACgkQnvQgOdby QH1GHg/9FoGt8kjKRW1G0ZskfjArJJ5Go4/wMZfiCYcoJ2Vx6xCLNPv5ccsxev02 VCLL29ta23u7Gj60P+jf3xUqEhkJdzGd3TnKHnLxp1dtXH1dnHQbyZGb5t0NGg59 UIrzIVq1vGEqpsc/VLEK4RLQ9HkUrUjIncmVRkjJiwWjkWehvumfExNzxDxjC1ww XelrYQC07bLnY5dP3WnoduIWuz+uuHyJj0hWBMSVRafFj58jj0k1F7Ii5iSyWtRt 7/QDnptozkoWGcW3GyBNVA34ChKtdY1eTwCKgDBvcm9+Bvho1OqN3bFTNr4pCpaZ SvxAuLqHvkTccmyCRy5QcH7TFbRQp0vfM+4rHHjBd2HQ2lJJ3IyDJUf4ky2nEKXr 1Tye6CL4c8nLKErZX3HDjng1sozU7mKQHw8XDqhGkQnHowlXlq21gBtewiEU5SnS 8MrTL+U4xyzS822wnro9mm86ehAgwpVB4Rrum1jKISf8SJvD9Dw4nmdiLXuwOtCO c2clQEh9Ae0q3jqZtic34XhZDiO7sXcEm9KCeaj637UbJr+vG5Svf3Oxregdj294 RqBHodu6RDhCdJJ9gUZqGb1SLEo503XAWeJu+Malij/Dvs+sZq9pkWUOoOEjmJNS 4EsdeIB8IW7eO01mo8wsnoZ9WhQwCWjLXrxm7AXFXzTvG7aq6ZU= =gaz+ -----END PGP SIGNATURE----- --N1GIdlSm9i+YlY4t--