Looker Connect Training

Help Center

Documentation

Community

Cloud Certifications

Question

Merge Queries & Row Limits - a word of warning

  • 6 December 2019
  • 8 replies
  • 1500 views
Kat_Lee
Userlevel 2

A word of warning around merge queries that we’ve just discovered, but is not made clear in the documentation:


When two queries are merged, the first 5000 rows are taken from each query and merged, regardless of what row limits you set in each query individually. So if you have a queries with potential results larger than 5000 rows, merge queries are not advised.


For example, if you were looking to merge a query of customer ID and order count, with a query of customer ID and complaint count, if your top ordering customer was the 5001th most frequent complainer, you would just see null for complaint count.


As such merge queries should be used with extreme caution with larger datasets to avoid misleading results

8 replies

babublacksheep

Thanks @Kat_Lee. We encountered a similar challenge recently where we had to flag our top 100 customers for yearly report segregated by months. We ended up using merge query and reporting wrong numbers.

J

Has anyone found a workaround? Even with the Download without Limit option it seems like the merged queries will still only pull the first 5000 records when downloading the csv.

er1k
Userlevel 5
Badge

+1 for updates on this.

madziekk

+1

A huge blocker in many situations.

R
Userlevel 1

+1 merge query is severely limited because of this. Also, the ability to set a row limit on the merged query would be useful

m-fernandes
Userlevel 2
Badge

Hi, I’ve created a feature request here, if you want to vote: Remove row limit on merges

dkrysl

Workaround is to filter in downstream (non-primary) explores on the same filters as in primary (only helpful if this gets you under the row limit of course)

KAEYV

Hi,

 

This is a real flaw for reports accross explores. Looking forward to have that resolved.

 

Some work arounds we use :

-Extend explore so the merge query is not required. (results in heavy explores and queries)

-Put a filter limit on the secondary queries based on the output (TOP so many) of the base query. (Copy/paste list in the filter field, works quite well) no so handy but it does the trick in cases where you look for a TOP xxxx (max 5000 :))

 

kr

Victor  

Reply


Terms of Service