Re: compute_query_id and pg_stat_statements

On Thu, May 13, 2021 at 12:11:12PM +0900, Kyotaro Horiguchi wrote:
> At Thu, 13 May 2021 10:43:03 +0800, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote in
> > On Thu, May 13, 2021 at 11:26:29AM +0900, Kyotaro Horiguchi wrote:
> > >
> > > I believe any "real"
> > > alternative query-id provider is supposed to be hooked "before"
> > > pg_stat_statements. (It is a kind of magic to control the order of
> > > plugins, though..
> >
> > Indeed, you have to configure shared_preload_libraries depending on whether
> > each module calls the previous post_parse_analyze_hook before or after its own
> > processing, and that's the main reason why I think a dedicated entry point
> > would be better.
>
> I see it as cleaner than the status-quo. (But still believing less
> cleaner than DLL:p, since the same problem happens if two
> query_id-generating modules are competing on the new hook ponit.).
>
> You told that a special query-id provider needed to be separated to
> another DLL

No, I'm saying a different entry point. It can be a new hook or an explicit
function name called for a dynamically loaded function, I'm fine with both as
long as it's called before post_parse_analyze_hook.

> It seems like the only problem doing that is we don't have a means to
> call per-process intializer for a preload libralies.

But that's going to happen only once per backend? If it's still adding too
much overhead you could add the module in shared_preload_libraries.