On Thu, Feb 5, 2015 at 10:28 AM, Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers