Try
Home   >   mailing lists

Re: track generic and custom plans in pg_stat_statements - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: track generic and custom plans in pg_stat_statements
Date
Msg-id CAA5RZ0sgLNBKUdceqvoxNCbn9rirJhH6bUjAmSZB6557cbcG4Q@mail.gmail.com
Whole thread Raw
In response to Re: track generic and custom plans in pg_stat_statements  (Andrei Lepikhov <lepihov@gmail.com>)
Responses Re: track generic and custom plans in pg_stat_statements
Re: track generic and custom plans in pg_stat_statements
List pgsql-hackers
Tree view 
> > The term "NOT_SET" makes me itch a little bit, even if there is an
> > existing parallel with OverridingKind.  Perhaps your proposal is OK,
> > still how about "UNKNOWN" instead to use as term for the default?
> +1 to "UNKNOWN".

We currently use both UNKNOWN and NOT_SET in different places.
However, I'm okay with using UNKNOWN, and I've updated it in v16.

> But generally, classification in the PlannedStmtOrigin structure seems a
> little strange: a generic plan has a qualitative difference from any
> custom one. And any other plan also will be generic or custom, doesn't
> it?

I am not sure I understand the reasoning here. Can you provide more details/
specific examples?

--
Sami
Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Improve prep_buildtree
Next
From: Corey Huinker
Date:
Subject: Re: CAST(... ON DEFAULT) - WIP build on top of Error-Safe User Functions