On 08/11/2021 14:48, Dmitry Yemanov wrote: > 08.11.2021 19:54, Adriano dos Santos Fernandes wrote: >> >> In this case I think we better sooner introduce MON$COMPILED_STATEMENTS >> with some duplicate information already present in MON$STATEMENTS, > > Obviously, SQL text and plan belong to the statement. The rest looks > request-specific (timestamp will represent request startup time). >
Yes. Some columns from MON$CALL_STACK also looks better to be present in MON$COMPILED_STATEMENTS: OBJECT_NAME, OBJECT_TYPE, PACKAGE_NAME. When compiled statement cache is present, more columns (for example, idle time). > However, MON$ATTACHMENT_ID is tricky. It's needed in > MON$COMPILED_STATEMENTS now, but likely to be not needed once the shared > statement cache is implemented. I don't think it's necessary now. MON$STATEMENTS.MON$COMPILED_STATEMENT_ID will point to it (MON$COMPILED_STATEMENTS.MON$COMPILED_STATEMENT_ID). Even if it's not true now, MON$COMPILED_STATEMENTS may appear as not directly linked to an attachment. > Also deprecate it then? Or maybe in the > future some statements could not be globally cacheable and instead > prepared per-attachment (as now)? > I think all statements should be split in MON$STATEMENTS and MON$COMPILED_STATEMENTS. Maybe the name MON$COMPILED_STATEMENTS does not look very good (as in this context MON$STATEMENTS also doesn't). >> declaring some columns of MON$STATEMENTS as deprecated to be removed in >> future versions. > > We never removed columns from system tables and I'm not sure this is a > good practice, as apps / components may have field names hardcoded / > cached. Returning NULL for deprecated columns should be perfectly > enough, IMO. > IMO returning NULL is worse as it hides possible problems. Tools will going to support the different ODS and may inadvertently use the always-NULL columns in new ODS. If remove them will not be an option, I think it's better to mirror they content. >> And make (now) MON$STATEMENTS ids represent request IDs generated on >> request start (for DSQL and routines). > > This may break existing apps (Dimitry Sibiryakov's question). But given > that an alternative (via new MON$ table) will be available, perhaps this > is not so critical. > It's what I also think. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
