From: | Karl Czajkowski <karlcz(at)isi(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: optimizing immutable vs. stable function calls? |
Date: | 2017-01-19 02:45:12 |
Message-ID: | 20170119024512.GE23081@moraine.isi.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Jan 18, Tom Lane modulated:
> Karl Czajkowski <karlcz(at)isi(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Clailson | 2017-01-19 10:08:47 | Optimization inner join |
Previous Message | David G. Johnston | 2017-01-19 00:09:20 | Re: optimizing immutable vs. stable function calls? |