when we execute a query, is there a away to find if query used regular QS vs data distiller ?

Even Data distiller use the same SQL engine. The difference between Data Distiller Vs Query Service is the capability of data distiller to schedule queries, and higher execution time, concurrent sessions and much more. but basically they both run on the same engine.

so i dont understand your question. why do you want to know where it get executed.

If you did not buy Data Distiller you are not able to use write commands like Insert Into etc

You are able to read only queries :)

In short, any Batch Queries, such as CTAS and ITAS, are Data Distiller. Due to the nature of these queries, they are writing new rows to a Dataset; any complex SELECT queries will need to be a Batch Query as they would time out as an interactive session.

Hi ​@Pradeep-Jaiswal, 
 

Yes, there's a way to tell — look at the computeGatewayJobId field in the query log.

When a query runs through Data Distiller, that field will have a value. When it runs through regular interactive Query Service, it'll be null. That's your clearest signal.

You can check it via the Query Service API:

GET https://platform.adobe.io/data/foundation/query/queries/{queryId}

{
  "id": "your-query-id",
  "computeGatewayJobId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"  // Data Distiller — has a value
  "computeGatewayJobId": null  // Regular QS — null
}

You can also see this in the UI under Queries > Log — open any query run and check the details panel.

That said, in most cases you can tell just from the query type itself. If you're running a SELECT for exploration in the UI, that's interactive QS. If you're running CTAS (CREATE TABLE AS SELECT) or INSERT INTO to write results to a dataset, that's Data Distiller — and it's drawing from your Data Distiller compute hours, not your interactive query allocation.

The reason this matters beyond curiosity: Data Distiller is SKU-based and has cost implications, so if something in your org is unexpectedly burning compute hours, auditing computeGatewayJobId across your query log via the API is the right way to track it down at scale.