https://www.gooddata.ai/ logo
Join Slack
Powered by
Hi Gooddata team, We're experiencing slow visuali...
# gooddata-cloud
a
Hi Gooddata team, We're experiencing slow visualization load times on our Redshift datasource and have traced the root cause to how GoodData generates SQL with timezone wrapping. The Problem: GoodData wraps date filter values in timezone() and to_timestamp() functions in the generated SQL: created_at >= timezone('Etc/UTC', to_timestamp('2026-2', 'YYYY-MM')::timestamp) Redshift cannot resolve these function-wrapped values at query plan time, which prevents it from using sort key zone maps for block skipping. Instead, it falls back to a full sequential scan. Evidence — Same query, two versions: 1. GoodData-generated (with timezone wrapper): EXPLAIN cost: 53,718 — full table scan 2. Hardcoded timestamps (no wrapper): created_at >= '2026-02-01 000000' EXPLAIN cost: 1,051 — sort key zone maps used That's a ~50x performance difference on the same table with the same sort key on created_at. Our Setup: - Redshift cluster, 2 nodes - Sort key: created_at (applied and fully sorted, unsorted = 0%) - Data is already stored in UTC Questions: 1. Is there a datasource or workspace setting to prevent the timezone() wrapping when our data is already in UTC? 2. Can GoodData be configured to emit pre-resolved timestamp literals instead of runtime function calls for Redshift? 3. Is this a known limitation with the Redshift SQL generator? Any guidance on eliminating the unnecessary timezone conversion in the generated SQL would resolve our performance issue immediately. Thank you
k
There is no mention in the available knowledge sources of a setting that changes how Redshift-specific SQL is generated for time zones, nor of a way to disable the 
timezone()
/ 
to_timestamp()
wrapping you’re seeing. What we do know from the docs: - Time zone conversion in GoodData is driven by the time zone hierarchy (org → workspace → user) and by the underlying DB data type. Conversion is only applied when the column is 
TIMESTAMPTZ
(or equivalent); for plain 
DATE
/ 
TIMESTAMP
, GoodData does not perform time zone conversion at all.[[Manage time zones](https://www.gooddata.com/docs/cloud/customize-appearance/manage-timezones/)] - For Redshift specifically, the public docs describe connection details, unsupported functions, and performance tips (sort keys, distribution, etc.), but they do not mention any configuration that alters how date/time filters are rendered in SQL or disables time zone wrapping.[[Redshift source](https://www.gooddata.com/docs/cloud/connect-data/create-data-sources/redshift/#additional-information)] Given that: 1. Is there a setting to prevent 
timezone()
wrapping? The knowledge sources do not show any organization, workspace, or data‑source setting that disables time zone wrapping or forces “raw” literals for Redshift. They only describe enabling/disabling conversion via data types (
TIMESTAMPTZ
vs `TIMESTAMP`/`DATE`) and time zone hierarchy, not the exact SQL shape.[[Manage time zones](https://www.gooddata.com/docs/cloud/customize-appearance/manage-timezones/)] 2. Can GoodData emit pre-resolved timestamp literals for Redshift? There is no documentation indicating that this behavior is configurable per data source or per workspace. The Redshift docs cover limits and performance recommendations, but not SQL‑generation toggles.[[Redshift source](https://www.gooddata.com/docs/cloud/connect-data/create-data-sources/redshift/#additional-information)] 3. Is this a known limitation with the Redshift SQL generator? The provided sources do not mention this specific Redshift planner/zone‑map issue or any related known issue. The only Redshift “known issues” documented are about trailing spaces in `WHERE`/`HAVING` and some unsupported statistical/window functions.[[Redshift source](https://www.gooddata.com/docs/cloud/connect-data/create-data-sources/redshift/#additional-information)] Because of that, I cannot point you to a documented switch that would immediately remove the 
timezone()
wrapping. Given the size of the performance gap you’ve measured and the fact that it’s tied to GoodData’s SQL shape rather than your schema, this is something you should raise with GoodData Support as a product/SQL‑generator issue. When you do, include: - The exact generated SQL (from 
/debug
on the visualization).[[Query debug](https://gooddataconnect.slack.com/archives/C04S1MSLEAW/p1771503457893699?thread_ts=1771503457.893699&cid=C04S1MSLEAW)] - The equivalent “literal” version and both 
EXPLAIN
plans. - Confirmation that your data is stored in UTC and that 
created_at
is the sort key. That will allow engineering to (a) confirm whether this is a Redshift‑specific limitation in the SQL generator and (b) consider an optimization (e.g., emitting literals when the workspace/org time zone is UTC and the column is already UTC). From the current documentation, though, there is no supported knob you can turn yourself to change this behavior.
j
Hi @Aryan Arora Could you please provide the following: The exact GoodData‑generated SQL (from the visualization’s debug output). Your hand‑written equivalent with literal timestamps. • Both 
EXPLAIN
plans showing the ~50× cost difference. • Confirmation that: • 
created_at
is the sort key, • Data is stored in UTC, • The workspace/org/user time zone is set (likely UTC) and why conversion is unnecessary in your case. You can send this in a DM if preferred
Hi @Aryan Arora I just wanted to follow up with you on this and see if you can provided the requested information above
r
Copy code
SELECT
	CASE
		WHEN "t2"."def_m_c843fbc362bd9fe20d49b7dd43d842a5" THEN "t2"."m_c843fbc362bd9fe20d49b7dd43d842a5"
		ELSE NULL
	END AS "m_1",
	CASE
		WHEN "t6"."def_m_c3da1b901bc068c18076ab1d3c28da9b" THEN "t6"."m_c3da1b901bc068c18076ab1d3c28da9b"
		ELSE NULL
	END AS "m_2",
	CASE
		WHEN "t2"."def_m_c843fbc362bd9fe20d49b7dd43d842a5"
		OR "t6"."def_m_c3da1b901bc068c18076ab1d3c28da9b" THEN CAST(
			CASE
				WHEN "t2"."def_m_c843fbc362bd9fe20d49b7dd43d842a5"
				OR "t6"."def_m_c3da1b901bc068c18076ab1d3c28da9b" THEN CASE
					WHEN "t2"."def_m_c843fbc362bd9fe20d49b7dd43d842a5" THEN COALESCE("t2"."m_c843fbc362bd9fe20d49b7dd43d842a5", 0.0)
					ELSE 0.0
				END - CASE
					WHEN "t6"."def_m_c3da1b901bc068c18076ab1d3c28da9b" THEN COALESCE("t6"."m_c3da1b901bc068c18076ab1d3c28da9b", 0.0)
					ELSE 0.0
				END
				ELSE 0.0
			END AS DOUBLE PRECISION
		) / NULLIF(
			CASE
				WHEN "t6"."def_m_c3da1b901bc068c18076ab1d3c28da9b" THEN COALESCE("t6"."m_c3da1b901bc068c18076ab1d3c28da9b", 0.0)
				ELSE 0.0
			END,
			0
		)
		ELSE NULL
	END AS "m_3"
FROM
	(
		SELECT
			SUM("net_revenue") AS "m_c843fbc362bd9fe20d49b7dd43d842a5",
			TRUE AS "def_m_c843fbc362bd9fe20d49b7dd43d842a5"
		FROM
			"bookee_demo"."gd_center_sales"
		WHERE
			"created_at" >= (TO_TIMESTAMP('2026-2', 'YYYY-MM')::TIMESTAMP) AT TIME ZONE 'Etc/UTC'
			AND "created_at" < (DATEADD ('month', 1, TO_TIMESTAMP('2026-2', 'YYYY-MM')::TIMESTAMP)) AT TIME ZONE 'Etc/UTC'
			AND "created_at" < (DATEADD ('day', 1, TO_TIMESTAMP('2026-2-20', 'YYYY-MM-DD')::TIMESTAMP)) AT TIME ZONE 'Etc/UTC'
		GROUP BY
			CAST(NULL AS INTEGER)
	) AS "t2",
	(
		SELECT
			SUM("net_revenue") AS "m_c3da1b901bc068c18076ab1d3c28da9b",
			TRUE AS "def_m_c3da1b901bc068c18076ab1d3c28da9b"
		FROM
			"bookee_demo"."gd_center_sales"
		WHERE
			"created_at" >= (DATEADD ('month', -1, TO_TIMESTAMP('2026-2', 'YYYY-MM')::TIMESTAMP)) AT TIME ZONE 'Etc/UTC'
			AND "created_at" < (DATEADD ('month', 1, DATEADD ('month', -1, TO_TIMESTAMP('2026-2', 'YYYY-MM')::TIMESTAMP))) AT TIME ZONE 'Etc/UTC'
			AND "created_at" < (DATEADD ('day', 1, DATEADD ('month', -1, TO_TIMESTAMP('2026-2-20', 'YYYY-MM-DD')::TIMESTAMP))) AT TIME ZONE 'Etc/UTC'
			AND CONVERT(TIMESTAMP, DATE_TRUNC('MONTH', ("created_at") AT TIME ZONE 'Etc/UTC')) IS NOT NULL
			AND CONVERT(TIMESTAMP, DATE_TRUNC('DAY', ("created_at") AT TIME ZONE 'Etc/UTC')) IS NOT NULL
		GROUP BY
			CAST(NULL AS INTEGER)
	) AS "t6"
WHERE
	"t2"."def_m_c843fbc362bd9fe20d49b7dd43d842a5"
	OR "t6"."def_m_c3da1b901bc068c18076ab1d3c28da9b";
this is the gooddata generated sql
y
Hi Rajat, Thanks for sharing the SQL querry with us. Kindly also share with us a direct link to the visualization with the issue, so that we can check this further.
6 Views
Open in Slack
PreviousNext
Powered by