public inbox for [email protected]  

help / color / mirror / Atom feed

From: Pavel Stehule <[email protected]>
To: Alexander Pyhalov <[email protected]>
Cc: Alexander Korotkov <[email protected]>
Cc: [email protected]
Cc: Ronan Dunklau <[email protected]>
Cc: Tom Lane <[email protected]>
Subject: Re: SQLFunctionCache and generic plans
Date: Tue, 31 Dec 2024 16:39:45 +0100
Message-ID: <CAFj8pRCoR9B+Ap70TQqWUa0PeeEk94D6VW20YbWN2Pm4b6-JMQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <8216639.NyiUUSuA9g@aivenlaptop>
	<[email protected]>
	<[email protected]>
	<CAPpHfdue9RVJKo33jKwrCeEXec0BTTH7CTxVcyXGMbfMExaGLA@mail.gmail.com>
	<[email protected]>

Hi

út 31. 12. 2024 v 16:36 odesílatel Alexander Pyhalov <
[email protected]> napsal:

> Hi.
>
> >> What should we do with "pre-parsed" SQL functions (when prosrc is
> >> empty)? How should we create cached plans when we don't have raw
> >> parsetrees?
> >> Currently we can create cached plans without raw parsetrees, but this
> >> means that plan revalidation doesn't work, choose_custom_plan()
> >> always returns false and we get generic plan. Perhaps, we need some
> >> form
> >> of GetCachedPlan(), which ignores raw_parse_tree?
> >
> > I don't think you need a new form of GetCachedPlan().  Instead, it
> > seems that StmtPlanRequiresRevalidation() should be revised.  As I got
> > from comments and the d8b2fcc9d4 commit message, the primary goal was
> > to skip revalidation of utility statements.  Skipping revalidation was
> > a positive side effect, as long as we didn't support custom plans for
> > them anyway.  But as you're going to change this,
> > StmtPlanRequiresRevalidation() needs to be revised.
> >
>
> Thanks for feedback.
>
> I've modifed StmtPlanRequiresRevalidation() so that it looks on queries
> command type.
> Not sure if it's enough or I have to recreate something more similar to
> stmt_requires_parse_analysis()
> logic. I was wondering if this can lead to triggering plan revalidation
> in RevalidateCachedQuery().
> I suppose not - as we plan in executor (so shouldn't catch userid change
> or see some changes in
> related objects. Revalidation would kill our plan, destroying
> resultDesc.
>
> Also while looking at this, fixed processing of instead of rules (which
> would lead to NULL execution_state).
> --
>

there are lot of fails found by tester

Please, can you check it?

regards

Pavel

> Best regards,
> Alexander Pyhalov,
> Postgres Professional

view thread (35+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: SQLFunctionCache and generic plans
  In-Reply-To: <CAFj8pRCoR9B+Ap70TQqWUa0PeeEk94D6VW20YbWN2Pm4b6-JMQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox