Hello,
We are running DHIS2 2.42 with Apache Doris 3.0.8 as the analytics database, against a PostgreSQL source with a datavalue table of about 875 million rows. We are trying to understand one step of the analytics export and would appreciate guidance on whether what we see is expected.
During ANALYTICS_TABLE, before any data is written, there is a consistent ~15 minute pause. We traced it to this query in JdbcAnalyticsTableManager.getDataYears():
select distinct(year) from ${datavalue} dv
inner join analytics_rs_periodstructure pes on dv.periodid=pes.periodid
where pes.startdate is not null and dv.lastupdated < '<start time>'
Doris reports: 902,621 ms, 875,500,100 rows scanned, 14.1 GB read, 2 rows returned. Reproduced on a second run at ~14m32s.
The cause appears to be that the two tables end up on opposite sides of the federation boundary. ${datavalue} is qualified via DorisSqlBuilder.qualifyTable() into pg_dhis.public.datavalue (PostgreSQL), while analytics_rs_periodstructure stays unqualified and resolves to the Doris-native replica. Doris cannot push a join across a JDBC catalog, so it streams the entire external side in. The Doris backend logs the statement it sends to PostgreSQL, and it carries no period restriction:
SELECT "periodid", "lastupdated" FROM "public"."datavalue"
WHERE ("lastupdated" < '2026-09-22 13:32:00')
Our question: both tables in this query exist in the source PostgreSQL database. analytics_rs_periodstructure is generated there by JdbcResourceTableStore and only afterwards copied into Doris by replicateAnalyticsResourceTables(). But the manager is constructed with @Qualifier("analyticsReadOnlyJdbcTemplate"), so the query runs on Doris.
Is there a reason getDataYears must execute against the analytics database rather than the source one? The result is a list of years, which we would expect to be identical either way. If running it on the source template is safe, it would remove a fixed ~15 minute cost from every analytics run on Doris.
The same shape is present on master (getDataYears, with the qualifier renamed to analyticsJdbcTemplate), so this does not look like something already fixed.
We are happy to raise this as a Jira issue if that is more useful. Versions: DHIS2 2.42.x, Apache Doris 3.0.8-rc01, PostgreSQL source, analytics.database = doris.