On Feb 18, 9:35 am, [EMAIL PROTECTED] (Tom Lane) wrote:
> Russell Smith <[EMAIL PROTECTED]> writes:
>
> > If you replan and immutable function, aren't you possibly messing up a
> > functional index that is using the old function. Hey, if you change an
> > immutable function that has an index, you
Simon Riggs wrote:
> On Sat, 2007-02-17 at 12:48 -0500, Tom Lane wrote:
>
> > Relcache inval casts a fairly wide net; for example, adding or dropping an
> > index will invalidate all plans using the index's table whether or not
> > they used that particular index, and I believe that VACUUM will al
On Sat, 2007-02-17 at 12:48 -0500, Tom Lane wrote:
> Relcache inval casts a fairly wide net; for example, adding or dropping an
> index will invalidate all plans using the index's table whether or not
> they used that particular index, and I believe that VACUUM will also
> result in a relcache inv
Gregory Stark wrote:
[snip]
Hm. The set of output columns could change? How?
If you prepare "select *" and add a column, you're saying the query should
start failing? That seems strange given the behaviour of views, which is that
once parsed the list of columns is written in stone. It seems
On 2/19/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
> If you prepare "select *" and add a column, you're saying the query should
> start failing?
Either fail or change output; which you like better? The whole point of
this exercise is to support plpgsql fun
Gregory Stark <[EMAIL PROTECTED]> writes:
> If you prepare "select *" and add a column, you're saying the query should
> start failing?
Either fail or change output; which you like better? The whole point of
this exercise is to support plpgsql functions that do something like
create temp
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Russell Smith <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> 2. Given a handle for a previously stored query, check to see if the plan
>>> is still up to date; if not, regenerate it from the raw parse tree (note
>>> this could result in failure, eg if a
Russell Smith <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> 2. Given a handle for a previously stored query, check to see if the plan
>> is still up to date; if not, regenerate it from the raw parse tree (note
>> this could result in failure, eg if a column used by the query has been
>> dropped)
Tom Lane wrote:
I'm starting to think about the long-wanted plan invalidation mechanism.
Here's a sketch --- anyone see any problems?
* Create a new module, say src/backend/utils/cache/plancache.c, that we
will put in charge of all long-lived plans --- or at least those cached by
PREPARE, plpgsq
Tom Lane wrote:
place. But the question to answer is why the re-plan won't yield
just the same plan as before.
oh and when the estimated cost repeatedly do not match the actual cost,
we of course want to generate an email with all relevant information
that is send to this list ;)
regards,
Tom Lane wrote:
Lukas Kahwe Smith <[EMAIL PROTECTED]> writes:
I remember that there was discussion about invalidating plans who's
estimated cost turn out to be severely off when executed.
That's something we might think about after the infrastructure is in
place. But the question to answer is
Lukas Kahwe Smith <[EMAIL PROTECTED]> writes:
> I remember that there was discussion about invalidating plans who's
> estimated cost turn out to be severely off when executed.
That's something we might think about after the infrastructure is in
place. But the question to answer is why the re-pla
Tom Lane wrote:
Relcache inval casts a fairly wide net; for example, adding or dropping an
index will invalidate all plans using the index's table whether or not
they used that particular index, and I believe that VACUUM will also
result in a relcache inval due to updating the table's pg_class r
I'm starting to think about the long-wanted plan invalidation mechanism.
Here's a sketch --- anyone see any problems?
* Create a new module, say src/backend/utils/cache/plancache.c, that we
will put in charge of all long-lived plans --- or at least those cached by
PREPARE, plpgsql, and RI triggers
14 matches
Mail list logo
