Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cid9g-0002b9-BA for pgsql-performance@arkaria.postgresql.org; Tue, 28 Feb 2017 08:29:08 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cid9f-0000XD-UL for pgsql-performance@arkaria.postgresql.org; Tue, 28 Feb 2017 08:29:07 +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.84_2) (envelope-from ) id 1cid7t-00051x-Jd for pgsql-performance@postgresql.org; Tue, 28 Feb 2017 08:27:17 +0000 Received: from shout02.mail.de ([2001:868:100:600::217]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cid7p-0006mT-OA for pgsql-performance@postgresql.org; Tue, 28 Feb 2017 08:27:15 +0000 Received: from postfix01.mail.de (postfix01.bt.mail.de [10.0.121.125]) by shout02.mail.de (Postfix) with ESMTP id 93A4E698A9; Tue, 28 Feb 2017 09:27:10 +0100 (CET) Received: from smtp04.mail.de (smtp04.bt.mail.de [10.0.121.214]) by postfix01.mail.de (Postfix) with ESMTP id 7BF2940087; Tue, 28 Feb 2017 09:27:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mail.de; s=mailde201610; t=1488270430; bh=7hyUe/WgS9BtsDxPn5KhswnKw/FaqRKEBL1kY8/yuFA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=UB8DOWbb3bRsF0hiRqDy6j+Bh/2hUHU7hdb0CEs0885KMOFgCY4dTiUcX55D958Xx ZjghJ8z27nG9Jsv2xwQu8Crbh4pWpL++2e99dUyLhXSILt7DnNIjubSyEIwRb22qoO MIDgXCsz+SlGe+9yzyl9Xly+Vx6DQrd7oAOiHAro= Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp04.mail.de (Postfix) with ESMTPSA id 173AE8002A; Tue, 28 Feb 2017 09:27:10 +0100 (CET) Subject: Re: Speeding up JSON + TSQUERY + GIN To: Jeff Janes References: <2260e4e6-89ae-90dc-278c-81243b3c3510@mail.de> Cc: "pgsql-performance@postgresql.org" From: "Sven R. Kunze" Message-ID: Date: Tue, 28 Feb 2017 09:27:09 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4DDC3F65B393A9F9AEE0D1D4" X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-purgate-size: 2597 X-purgate-ID: 154282::1488270430-000070F2-FCF61F78/0/0 X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org This is a multi-part message in MIME format. --------------4DDC3F65B393A9F9AEE0D1D4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 27.02.2017 19:22, Jeff Janes wrote: > If by 'permanently', you mean even when you intentionally break > things, then no. You will always be able to intentionally break > things. There is on-going discussion of an auto-prewarm feature. But > that doesn't yet exist; and once it does, a super user will always be > able to break it. > > Presumably you have a use-case in mind other than intentional sabotage > of your caches by root. But, what is it? If you reboot the server > frequently, maybe you can just throw 'select pg_prewarm...' into an > init script? I didn't express myself well enough. pg_prewarm doesn't help to speed up those queries at all. Looking at these numbers, I wonder why it takes ~5 secs to answer? Best, Sven --------------4DDC3F65B393A9F9AEE0D1D4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 27.02.2017 19:22, Jeff Janes wrote:
If by 'permanently', you mean even when you intentionally break things, then no.  You will always be able to intentionally break things.  There is on-going discussion of an auto-prewarm feature.  But that doesn't yet exist; and once it does, a super user will always be able to break it.

Presumably you have a use-case in mind other than intentional sabotage of your caches by root.  But, what is it?  If you reboot the server frequently, maybe you can just throw 'select pg_prewarm...' into an init script?

I didn't express myself well enough. pg_prewarm doesn't help to speed up those queries at all.


Looking at these numbers, I wonder why it takes ~5 secs to answer?


Best,
Sven
--------------4DDC3F65B393A9F9AEE0D1D4--