Re: invalidating cached plans - Mailing list pgsql-hackers

From Tom Lane
Subject Re: invalidating cached plans
Date
Msg-id 3040.1110866424@sss.pgh.pa.us
Whole thread Raw
In response to Re: invalidating cached plans  ("Qingqing Zhou" <zhouqq@cs.toronto.edu>)
List pgsql-hackers
"Qingqing Zhou" <zhouqq@cs.toronto.edu> writes:
> This is the key point (say this is point_1) - we must make sure how deep we
> have to go to check validity.

The recorded plan has to somehow mention all the inlined functions that
were expanded out of existence.  There might be several levels of such
things, but as long as we remember them all for invalidation purposes,
I don't see a problem.

A related example: an operator might point to an inline-able function.
Neither the operator nor the function will appear explicitly in the
finished plan tree, but they'd better both be listed in the side list
of invalidation dependencies.

> I don't quite understand the difference between a SQL function and a
> PL/PgSQL function here -

The planner doesn't know anything about inlining plpgsql functions.
So while the function might have its own invalidation issues to deal
with internally, a plan that calls it cannot need invalidation because
of that.

Obviously these issues depend a lot on the internal behavior of the
planner, so we are going to have to fix the planner to record the
identity of every object that it looks at without explicitly mentioning
it in the final plan.  No other part of the system can be expected
to track all that.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: invalidating cached plans
Next
From: Christopher Kings-Lynne
Date:
Subject: PQexecParams