From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Pedro França <pedro(dot)franca(at)golsat(dot)com(dot)br>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Getting an optimal plan on the first execution of a pl/pgsql function |
Date: | 2015-12-14 20:41:57 |
Message-ID: | 5607.1450125717@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Mon, Dec 14, 2015 at 11:53 AM, Pedro Frana <pedro(dot)franca(at)golsat(dot)com(dot)br>
> wrote:
>> When I test with EXPLAIN ANALYZE after the first execution, the query runs
>> really fast but the aplication sessions call the function only once and
>> then are terminated. I need that the first execution use the actual
>> optimized plan.
> Your problem that the performance improvement is
> seen due to caching effects. If you throw away the cache you loose the
> improvement.
Yeah. And it's not only the function itself, it's catalog caches and a
bunch of other stuff. Basically, you should expect that the first few
queries executed by any PG session are going to be slower than those
executed later. If you can't fix your application to hold sessions open
for a reasonable amount of time, use a connection pooler to do it for you
(pgpooler for instance).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pedro França | 2015-12-14 20:50:56 | Re: Getting an optimal plan on the first execution of a pl/pgsql function |
Previous Message | David G. Johnston | 2015-12-14 19:21:54 | Re: Getting an optimal plan on the first execution of a pl/pgsql function |