Date: Wed, 18 Jan 2017 18:45:12 -0800
From: Karl Czajkowski <karlcz@isi.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: optimizing immutable vs. stable function calls?
Message-ID: <20170119024512.GE23081@moraine.isi.edu>
References: <20170118223633.GC23081@moraine.isi.edu>
 <14964.1484780049@sss.pgh.pa.us>
 <20170118230646.GD23081@moraine.isi.edu>
 <16252.1484781941@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16252.1484781941@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On Jan 18, Tom Lane modulated:
> Karl Czajkowski <karlcz@isi.edu> writes:
> > Is there a correctness hazard with pretending our function is
> > IMMUTABLE, even though we will change the underlying config parameter
> > in the same connection?
> 
> You could probably get away with that if you never ever use prepared
> queries (beware that almost anything in plpgsql is a prepared query).
> It's a trick that's likely to bite you eventually though.
> 

That sounds unnerving. I think I need to play it safe. :-/

Does the plan cache disappear with each connection/backend process?
Or is there also a risk of plans being shared between backends?

Would it be invasive or a small hack to have something like
"transaction-immutable" which can be precomputed during planning, like
immutable, but then must discard those plans at the end of the
transaction...?


karl


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance