Re: Getting an optimal plan on the first execution of a pl/pgsql function

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

In response to

Responses

Browse pgsql-performance by date

  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