RE: Planning counters in pg_stat_statements (using pgss_store)
От | imai.yoshikazu@fujitsu.com |
---|---|
Тема | RE: Planning counters in pg_stat_statements (using pgss_store) |
Дата | |
Msg-id | OSBPR01MB461601EA9F13C089C3157E6894FD0@OSBPR01MB4616.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Planning counters in pg_stat_statements (using pgss_store) (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: Planning counters in pg_stat_statements (using pgss_store)
|
Список | pgsql-hackers |
Hi Julien, On Mon, Mar 9, 2020 at 10:32 AM, Julien Rouhaud wrote: > On Thu, Mar 05, 2020 at 01:26:19PM -0700, legrand legrand wrote: > > Please consider PG13 shortest path ;o) > > > > My one is parse->queryId != UINT64CONST(0) in pgss_planner_hook(). > > It fixes IVM problem (verified), > > and keep CTAS equal to pgss without planning counters (verified too). > > I still disagree that hiding this problem is the right fix, but since no one > objected here's a v5 with that behavior. Hopefully this will be fixed in v14. Is there any case that query_text will be NULL when executing pg_plan_query? If query_text will be NULL, we need to add codes to avoid errors in pgss_store like as current patch. If query_text will not be NULL, we should add Assert in pg_plan_query so that other developers can notice that they would not mistakenly set query_text as NULL even without using pgss_planning counter. -- Yoshikazu Imai
В списке pgsql-hackers по дате отправления: