This parameter, used with suggest_dimension, changes how Looker generates suggestions for a filter field or a dimension of type: string when someone uses that field to filter a query.
Looker typically generates these suggestions by executing the following query on the filter field:
SELECT DISTINCT <field name> FROM <table> LIMIT 1000
If the field is in a large table, this query can be too slow or create too large a database load.
By using suggest_dimension, you can make Looker query an alternative dimension for the suggestion values. If that dimension is defined in a different Explore, suggest_explore tells Looker where to find it. In this case, in the suggest_dimension parameter, include both the view name where the dimension is defined and the dimension name in the format view_name.field_name. In addition, ensure that the view is joined to the Explore that is specified in the suggest_explore parameter.
If the dimension is defined in the current view, suggest_explore is not required.
Examples
In this example, instead of looking through a huge list of user names from the event table, we've told Looker to query the names from a user table:
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-14 UTC."],[],[],null,["# suggest_explore\n\n\u003cbr /\u003e\n\nUsage\n-----\n\n```\nview: view_name {\n dimension: field_name {\n suggest_explore: explore_name\n }\n}\n```\n\nDefinition\n----------\n\nThis parameter, used with [`suggest_dimension`](/looker/docs/2512/reference/param-field-suggest-dimension), changes how Looker generates suggestions for a [`filter`](/looker/docs/2512/reference/param-field-filter) field or a [`dimension`](/looker/docs/2512/reference/param-field-dimension) of `type: string` when someone uses that field to filter a query.\n\nLooker typically generates these suggestions by executing the following query on the filter field:\n\n`SELECT DISTINCT \u003cfield name\u003e FROM \u003ctable\u003e LIMIT 1000`\n\nIf the field is in a large table, this query can be too slow or create too large a database load.\n\nBy using `suggest_dimension`, you can make Looker query an alternative dimension for the suggestion values. If that dimension is defined in a different Explore, `suggest_explore` tells Looker where to find it. In this case, in the `suggest_dimension` parameter, include both the view name where the dimension is defined and the dimension name in the format `view_name.field_name`. In addition, ensure that the view is [joined](/looker/docs/2512/working-with-joins) to the Explore that is specified in the `suggest_explore` parameter.\n\nIf the dimension is defined in the current view, `suggest_explore` is not required.\n\nExamples\n--------\n\nIn this example, instead of looking through a huge list of user names from the `event` table, we've told Looker to query the names from a `user` table: \n\n dimension: event_user_name {\n type: string\n sql: ${TABLE}.event_user_name ;;\n suggest_explore: user\n suggest_dimension: user.name\n }"]]