From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | "Sven R(dot) Kunze" <srkunze(at)mail(dot)de> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Speeding up JSON + TSQUERY + GIN |
Date: | 2017-02-28 16:49:42 |
Message-ID: | CAMkU=1yWkWfZEZ=ANm-bWrDHBm869MCyRmyJDx5kbeCwJC_w2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Feb 28, 2017 at 12:27 AM, Sven R. Kunze <srkunze(at)mail(dot)de> wrote:
> 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.
>
Oh. In my hands, it works very well. I get 70 seconds to do the {age: 20}
query from pure cold caches, versus 1.4 seconds from cold caches which was
followed by pg_prewarm('docs','prefetch').
How much RAM do you have? Maybe you don't have enough to hold the table in
RAM. What kind of IO system? And what OS?
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Sven R. Kunze | 2017-03-01 14:02:15 | Re: Speeding up JSON + TSQUERY + GIN |
Previous Message | Sven R. Kunze | 2017-02-28 08:27:09 | Re: Speeding up JSON + TSQUERY + GIN |