Re: Early Setup of instrumentation information in pg_stat_statements
От | Robert Haas |
---|---|
Тема | Re: Early Setup of instrumentation information in pg_stat_statements |
Дата | |
Msg-id | CA+TgmobZs+ZOPpVywXFT__gtWi02No7mCwZE9CEcYPUysKNy6w@mail.gmail.com обсуждение исходный текст |
Ответ на | Early Setup of instrumentation information in pg_stat_statements (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Thu, Feb 5, 2015 at 10:28 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > Currently in pg_stat_statements, the setup to track > instrumentation/totaltime information is done after > ExecutorStart(). Can we do this before ExecutorStart()? > In particular, I am referring to below code: > > static void > pgss_ExecutorStart(QueryDesc *queryDesc, int eflags) > { > .. > standard_ExecutorStart(queryDesc, eflags); > .. > if (pgss_enabled() && queryDesc->plannedstmt->queryId != 0) > { > .. > if (queryDesc->totaltime == NULL) > { > .. > queryDesc->totaltime = InstrAlloc(1, INSTRUMENT_ALL); > .. > } > } > } > > The reason why I am asking is that to track instrumentation > information (like buffer usage parameters) in case of parallel > sequence scan, we need to pass this information at start of > backend workers which are started in ExecutorStart() phase > and at that time, there is no information available which can > guarantee (we have queryId stored in planned stmt, but I think > that is not sufficient to decide) that such an information is > needed by plugin. This works well for Explain statement as > that has the information for instrumentation available before > ExecutorStart() phase. > > Please suggest me if there is a better way to make this > information available in ExecutorStart() phase? This seems like a clue that maybe starting the workers during the ExecutorStart() phase is a bad idea. It might be a bad idea for other reasons, too: what happens if that node never gets executed? I think the general pattern of executor nodes is that they're not supposed to do any real work until somebody tries to pull a tuple from them. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: