public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andrey V. Lepikhov <[email protected]>
To: Tom Lane <[email protected]>
Cc: PostgreSQL-Dev <[email protected]>
Subject: Re: Clarify planner_hook calling convention
Date: Tue, 4 Jan 2022 15:44:53 +0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>

On 1/3/22 8:59 PM, Tom Lane wrote:
> "Andrey V. Lepikhov" <[email protected]> writes:
>> planner hook is frequently used in monitoring and advising extensions.
> 
> Yeah.
> 
>> The call to this hook is implemented in the way, that the
>> standard_planner routine must be called at least once in the hook's call
>> chain.
>> But, as I see in [1], it should allow us "... replace the planner
>> altogether".
>> In such situation it haven't sense to call standard_planner at all.
> 
> That's possible in theory, but who's going to do it in practice?

We use it in an extension that freezes a plan for specific parameterized 
query (using plancache + shared storage) - exactly the same technique as 
extended query protocol does, but spreading across all backends.
As I know, the community doesn't like such features, and we use it in 
enterprise code only.

>> But, maybe more simple solution is to describe requirements to such kind
>> of extensions in the code and documentation (See patch in attachment)?
>> + * 2. If your extension implements some planning activity, write in the extension
>> + * docs a requirement to set the extension at the begining of shared libraries list.
> 
> This advice seems pretty unhelpful.  If more than one extension is
> getting into the planner_hook, they can't all be first.

I want to check planner_hook on startup and log an error if it isn't 
NULL and give a user an advice how to fix it. I want to legalize this 
logic, if permissible.

> 
> (Also, largely the same issue applies to very many of our other
> hooks.)

Agreed. Interference between extensions is a very annoying issue now.

-- 
regards,
Andrey Lepikhov
Postgres Professional

view thread (3+ messages)

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]
  Subject: Re: Clarify planner_hook calling convention
  In-Reply-To: <[email protected]>

* 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