Data Engineering Zoomcamp 2026

Homework 3: Data Warehousing Statistics

Distribution of scores and reported study time for this homework.

Submissions

872

Median total score

Average total score

Score distribution

All values are points.

Metric	Min	Q1	Median	Average	Q3	Max
Questions score	-	7.0	8.0	7.5	8.0	8
Learning in public score	-	0.0	0.0	0.6	1.0	7
Total score	-	8.0	8.0	8.1	9.0	16

Questions score

Min: -
Median: 8.0
Max: 8
Q1: 7.0
Avg: 7.5
Q3: 8.0

Learning in public score

Min: -
Median: 0.0
Max: 7
Q1: 0.0
Avg: 0.6
Q3: 1.0

Total score

Min: -
Median: 8.0
Max: 16
Q1: 8.0
Avg: 8.1
Q3: 9.0

Time distribution

All values are hours reported by students.

Metric	Min	Q1	Median	Average	Q3	Max
Lectures	0.0	2.0	3.0	5.8	6.0	108.0
Homework	0.0	2.0	3.0	4.2	4.0	108.0

Lectures

Min: 0.0
Median: 3.0
Max: 108.0
Q1: 2.0
Avg: 5.8
Q3: 6.0

Homework

Min: 0.0
Median: 3.0
Max: 108.0
Q1: 2.0
Avg: 4.2
Q3: 4.0

Question breakdown

Correctness and answer distribution per question.

1. What is count of records for the 2024 Yellow Taxi Data?

835 / 872 correct (95.8%)

1 65,623 5 (0.6%)

2 840,402 10 (1.1%)

3 20,332,093 836 (95.9%)

4 85,431,289 15 (1.7%)

2. What is the estimated amount of data that will be read when this query is executed on the External Table and the Table?

739 / 872 correct (84.7%)

1 18.82 MB for the External Table and 47.60 MB for the Materialized Table 51 (5.8%)

2 0 MB for the External Table and 155.12 MB for the Materialized Table 739 (84.7%)

3 2.14 GB for the External Table and 0MB for the Materialized Table 46 (5.3%)

4 0 MB for the External Table and 0MB for the Materialized Table 29 (3.3%)

3. Why are the estimated number of Bytes different?

848 / 872 correct (97.2%)

1 BigQuery is a columnar database, and it only scans the specific columns requested in the query. Querying two columns (PULocationID, DOLocationID) requires reading more data than querying one column (PULocationID), leading to a higher estimated number of bytes processed. 849 (97.4%)

2 BigQuery duplicates data across multiple storage partitions, so selecting two columns instead of one requires scanning the table twice, doubling the estimated bytes processed. 5 (0.6%)

3 BigQuery automatically caches the first queried column, so adding a second column increases processing time but does not affect the estimated bytes scanned. 8 (0.9%)

4 When selecting multiple columns, BigQuery performs an implicit join operation between them, increasing the estimated bytes processed 2 (0.2%)

4. How many records have a fare_amount of 0?

794 / 872 correct (91.1%)

1 128,210 29 (3.3%)

2 546,578 36 (4.1%)

3 20,188,016 6 (0.7%)

4 8,333 795 (91.2%)

5. What is the best strategy to make an optimized table in Big Query if your query will always filter based on tpep_dropoff_datetime and order the results by VendorID (Create a new table with this strategy)

835 / 872 correct (95.8%)

1 Partition by tpep_dropoff_datetime and Cluster on VendorID 836 (95.9%)

2 Cluster on by tpep_dropoff_datetime and Cluster on VendorID 10 (1.1%)

3 Cluster on tpep_dropoff_datetime Partition by VendorID 7 (0.8%)

4 Partition by tpep_dropoff_datetime and Partition by VendorID 12 (1.4%)

6. Write a query to retrieve the distinct VendorIDs between tpep_dropoff_datetime 2024-03-01 and 2024-03-15 (inclusive). Use the materialized table you created earlier in your from clause and note the estimated bytes. Now change the table in the from clause to the partitioned table you created for question 5 and note the estimated bytes processed. What are these values?

845 / 872 correct (96.9%)

1 12.47 MB for non-partitioned table and 326.42 MB for the partitioned table 5 (0.6%)

2 310.24 MB for non-partitioned table and 26.84 MB for the partitioned table 845 (96.9%)

3 5.87 MB for non-partitioned table and 0 MB for the partitioned table 6 (0.7%)

4 310.31 MB for non-partitioned table and 285.64 MB for the partitioned table 7 (0.8%)

7. Where is the data stored in the External Table you created?

834 / 872 correct (95.6%)

1 Big Query 15 (1.7%)

2 Container Registry 5 (0.6%)

3 GCP Bucket 834 (95.6%)

4 Big Table 14 (1.6%)

8. It is best practice in Big Query to always cluster your data:

809 / 872 correct (92.8%)

1 True 59 (6.8%)

2 False 810 (92.9%)

9. Write a `SELECT count(*)` query FROM the materialized table you created. How many bytes does it estimate will be read? Why?

0 / 872 correct (0.0%)

Answer	Count
0 bytes	8
0	7
0B	4
SELECT COUNT(*) FROM `zoomcamp.yellow_tripdata_2024`;	3
0 MB	3
0 B	3
0 Bytes	3
SELECT COUNT(*) FROM `cohesive-folio-485508-e4.zoomcamp.materialized_yellow_tripdata` ;	2
0 bytes, BigQuery stores row count in table metadata and doesn't need to scan any data.	2
SELECT count(*) FROM `taxi-rides-ny-485214.ny_taxi_bigquery_dataset.external_yellow_tripdata`	2
The query processes 0 bytes because BigQuery retrieves the row count from the table's metadata, avoiding a full table scan. This is an optimization specific to COUNT(*) queries without filters or transformations.	1
SELCT COUNT() FROM kestra-demo-486219.zoomcamp.yellow_tripdata_materialized_2024; 0 Byte. Because BigQuery doesn't need to scan the table data to compute COUNT() on a native table in our case the materialized table created from the external yellow trip data records. BigQuery used table meta data to compute COUNT(*) without scanning table data, no columns are read.	1
SELECT COUNT() FROM `nyc-taxi-data.yellow_taxi_2024.yellow_tripdata_materialized`; 0 MB (or very close to 0 MB) BigQuery already keeps track of how many rows are in the table, so when you run a simple COUNT(), it doesn’t need to scan all the data again. It can answer the question using the table’s internal metadata. Also, if the query was run before, BigQuery may return the result from cache, which is why the estimated bytes can show as 0 MB.	1
0 bytes BigQuery can retrieve the row count from metadata, without scanning any data	1
Because total record got from metadata, not physically do count. Table metadata have information like total record etc.	1
The estimated bytes read will be equal to the total size of the materialized table, as no filtering is applied.	1
I initially thought it might take lot of bytes. However, I saw 0B in the estimate. Maybe, it has the count information in the metadata itself.	1
SELECT COUNT() FROM `ny_taxi_hw_week3.yellow_tripdata_non_partitoned`; Explanation: - There is 0B when run. Because the estimated data processed is 0 Bytes. This is because for native tables, BigQuery stores the row count in the table's metadata. When you run COUNT(), BigQuery retrieves this value directly from the metadata without scanning any actual data in the storage."	1
Query SELECT COUNT() FROM `de-2026-workshop.de_zoomcamp.yellow_taxi`; Observation Estimated bytes may show 0 in some cases. Reasoning (why 0 can happen) BigQuery may answer COUNT() from table metadata/statistics without scanning data blocks. If query results are cached, the UI can also report 0 bytes processed. To test caching effects: BigQuery UI → Query settings → disable Use cached results Re-run the query.	1
The estimated amount of bytes read is 0. This is because the number of rows in a materialized table is already stored as storage data; the row count can be seen in the 'details' tab of the table without having to run a query.	1
The estimate will be 0 bytes because BigQuery uses metadata caching for its native storage.	1
0 select count(*) from `dtc-de-course-484822.zoomcampdwhw3.yellow_tripdata`;	1
0 bytes. Because it has this information cached	1
The estimated byte comes up as 0 B. I believe this is so because we are doing a count all which doesn't require scanning through all the columns. So the full dataset is not scanned because the table is already materialized in BigQuery. Also, metadata is used which aids faster scanning as well.	1
0 byte.BigQuery keeps metadata statistics about tables, including number of rows, partition info, storage blocks.BigQuery can read the row count from metadata without scanning the actual data.	1
SELECT count(*) FROM `External_Yellow_Taxi.native_yellow_taxi`; Estimated 0B data use. I assume it is because the table is not being filtered and no data quota is used to search. The table is simply displayed as is with no computing power needed.	1
Big Query using metadata not scan data, because in metadata there is an information about data count.	1
0 bytes BigQuery doesn’t actually scan the entire data, as there is no where clause. It just looks at the table's "ledger" to see how many rows are listed. Since it didn’t have to "read" the columns or the storage blocks, the bytes processed is 0.	1
SELECT COUNT(*) FROM `zoomcamp-module3-486307.zoomcamp.yellow_tripdata_non_partitioned` estimate is 0 byte because the calculation have been done it will just fetch the result	1
0 B scanned as Big Query can get this info from the metadata	1
0 B - because BigQuery can satisfy COUNT(*) using table metadata/statistics for the materialized table, so it doesn’t need to scan the underlying data.	1
0b Because BQ use metadata to this question instead of scan over the dataset.	1
SELECT COUNT() FROM nyc_taxi.yellow_tripdata_2024; 0B BigQuery stores metadata that has the number of rows in the table. The SELECT COUNT() uses the metadata instead of having to scan the table.	1
It shows 0 bytes because BQ has a feature that uses its internal metadata to show the number of records in the materialized table which means no need to scan the whole table that saves us costs.	1
This because the rows number of the materialized table can be get it thorught the table's metadata	1
This query will process 0 B when run. It is cache as the counts are already executed.	1
Zero Bytes, since this is read directly from the table's metadata rather than the actual storage.	1
SELECT count(*) from `taxi_rides_ny.nytaxi_fhv_nonpartitioned_tripdata`; What estimated bytes are read is 0 bytes because the information can get from Metadata Operations or Query Results Cache.	1
0B. The number of rows is already available in the table's metadata, so it does not need to scan the table.	1
0B because the number of rows in the table is already stored a BigQuery metadata so no scan is required.	1
SELECT COUNT(*) FROM `kestra-sandbox-zc.zoomcamp.yellow_tripdata` 0 byte estimated. It doesn't read each column. It aggregates the whole column into a single number.	1
SELECT COUNT(*) FROM `de-zoomcamp-2026-486008.ny_taxi.yellow_taxi_2024_non_partitioned`; ---- answer is 0 bytes because BigQuery doesn't own the files in or GCS bucket.	1
SELECT COUNT() FROM `kestra-study.kestra_study_dataset_xyz.yellow_tripdata_2024_01_06_partition_cluster`; 0 byte SELECT COUNT() can be answered using metadata only, without scanning the actual table data	1
'0 B' - Due to being a count query, it's the amount provided by the metadata.	1
It estimate 130.79 KB when run but actual bytes processed in 0B. This is because BigQuery returned a cached result from the previous query.	1
Select count(*) from `kestra-lk.zoomcamp.yellow_taxi_optimized` 0 Cost = Because 0 bytes are processed, these types of "metadata-only" queries are completely free of charge.	1
Answer: This query will process 0 B when run. Reason: BigQuery does not need to scan the actual table data to answer this specific query. Why? 1. Metadata Storage: BigQuery maintains metadata about every table separately from the actual data storage. This metadata includes the total row count of the table. 2. Optimization: When you execute a SELECT count() query without any WHERE clause or filters, BigQuery is smart enough to retrieve the row count directly from this metadata. 3. No Table Scan: Since it reads the value from metadata, it avoids scanning the underlying storage columns entirely. Consequently, the "bytes processed" metric remains at 0; however, if you adjust the query from SELECT count() to SELECT count(column_name), BigQuery would be forced to scan the actual data, and the bytes processed would no longer be zero.	1
It would be 0 bytes because that information is already included in the metadata, so it's not actually going to go through the data and count all the rows	1
0 Bytes. It estimates to read 0 bytes because BigQuery stores table metadata on the total count of rows.	1
0 MB. I think because this information is already stored, the number of rows. We can view that in the metadata.	1
0 Byte	1
0 B because for count(*) the engine can reference the metadata of the materialized table and BQ does not need to scan the table. If we add condition filter, the engine will have to scan data and this will involve usage.	1
The query process 0 bytes because BigQuery already knows number of rows from table metadata and can return the result without scanning the underlying data.	1
-- 0 MB SELECT COUNT() FROM `taxidata2024.taxidata_2024_01_06_materialised`; -- BigQuery uses metadata for COUNT() on native tables. When running COUNT(*) on the materialised table, BigQuery does not scan the full table. Instead, it uses precomputed metadata.	1
The estimated processing is 0 B, this is because BigQuery is reading from metadata (Number of rows), not the actual data files.	1
0B, it checks the metadata	1
It estimates 0, because COUNT(*) without filters is essentially free, as it uses cached metadata rather than scanning table data.	1
0 MB as BigQuery does not scan the underlying base table and get the row counts from the metadata	1
SELECT COUNT(*) FROM `zoomcamp-airflow-486119.hw3.yellow`; BigQuery uses storage-level metadata and block statistics to compute row counts without scanning column data, which results in 0 MB estimated bytes processed.	1
SELECT COUNT(*) FROM `norse-breaker-452400-q4.zoomcamp_m3.yellow_tripdata_2024`; the estimated bytes shows 0B, becasue GBQ cached the query result before when I was solving the previous questions.	1
SELECT COUNT() FROM `bigqrery-demo.zoomcamp.yellow_tripdata_native`; Estimated bytes read: 0 MB BigQuery can answer COUNT() from table metadata without scanning any columns.	1
155.12 MB. BigQuery has full metadata and statistics about the data, so It can accurately calculate exactly how many bytes will be scanned	1
SELECT COUNT() FROM `dtc-de-course-484520.nytaxi.yellow_tripdata_2024`; It reads 0B, BigQuery stores table metadata including row counts, COUNT() doesn't need to scan actual data so BigQuery returns the count directly from metadata. No columns read = 0 bytes processed	1
0 bytes because Big Query uses Metadata to read the total number of rows therefore scanning the table is not necessary.	1
SELECT COUNT () FROM Ma_materialized_table; 0 MB As BigQuery only reads metadata in COUNT () and doesn't read the data itself	1
SELECT count(*) FROM `datawarehouse.yellow_taxi_data` BigQuery can often answer using metadata only (row group counts in Parquet) without scanning the actual data blocks.	1
This query will process 0 B when run. This is because BigQuery caches metadata about row counts.	1
Answer: 0 MB The query will process 0 MB, because due the columnar storage used by Bigquery, with the aggregation function COUNT(*) we are not specifyng any column to be scanned, so when the query is executed the records count output is obtained from the metadata of the table without scanning other columns or additional info.	1
I get 0mb in bytes when I run this query on my regular table. This is because BigQuery is able to execute and return the value based purely on the tables metadata, without needing to perform a scan on the table.	1
0 Bytes and BigQuery stores the row count in the table's metadata. A COUNT(*) query on a native table retrieves this pre-calculated value without scanning the actual data blocks.	1
The estimated bytes read is 0 MB because BigQuery can compute COUNT(*) using table metadata without scanning the underlying data. Since no columns are accessed, no data blocks are read.	1
SELECT COUNT(*) FROM `zoomcamp-project-486920.zoomcamp_dw.yellow_2024_raw`; ## 0 Byte	1
It estimates 0 B because it reads from metadata.	1
0B. Because: BigQuery maintains metadata for native tables, including the total row count. When executing a `COUNT(*)` without filters, BigQuery retrieves this value directly from the metadata, avoiding any data scanning costs.	1
0MB. In BigQuery, a materialized table column data is stored alongside its metadata. so when SELECT count(*) is queried, the row count is returned from the metadata.	1
SELECT COUNT(*) from de-zoomcamp-ramani-2026.nyc_taxi_bq.yellow_tripdata_non_partitioned; 0 Bytes. Because it uses table metadata to fetch the count as no specific columns are there in the query. So no table scan.	1
0 bytes. Number of rows was retrieved from the metadata.	1
SELECT COUNT() FROM `de-zoomcamp-2026.taxi_data.yellow_taxi_materialized`; Estimated Bytes: 0 MB Why? BigQuery maintains metadata statistics including row counts. For a simple COUNT(): Doesn't need to scan actual data Uses cached metadata Result: 0 MB estimated, instant response! However, if you use COUNT() with a WHERE clause: sqlSELECT COUNT() FROM `project.dataset.yellow_taxi_materialized` WHERE fare_amount > 10; Now it needs to scan the fare_amount column → ~80 MB estimated	1
SELECT COUNT(*) FROM ny_taxi.yellow_tripdata;	1
SELECT COUNT(*) FROM `kestra-sandbox-486207.nyc_taxi.yellow_2024_tripdata_materialized`; 0Mb expected because it gets from the answer from metadata.	1
SELECT COUNT(*) FROM `dlt_yellow_taxi_dataset.yellow_taxi`; When executed this will process 0 B because this is the materialised view stored in the same project/dataset. Another reason is because since there are already earlier executions of this query its returning 0 B as processing because of metadata which does need to scan the actual files.	1
0 bytes. BigQuery uses table metadata to calculate count(*) for native tables without scanning the actual data.	1
0 B, becase it is answered entirely from the table's metadata.	1
SELECT COUNT(*) FROM kestra-sandbox-486404.zoomcamp.yellow_tripdata_2024; Why: The query estimates 0 B processed because BigQuery retrieves the total row count from table metadata instead of scanning the underlying data. Since no columns or filters are applied, the query can be answered using internal statistics without reading any data blocks.	1
SELECT count(*) FROM materialized_table	1
select count() from `dataeng-proj.yellow_tripdata.2024_non_partitioned`; Estimated bytes is 0, because we are counting on , which is not a column in table.	1
-- 9) SELECT COUNT() FROM wygolde.ny_taxi_data.matTaxiData -- estimated size: 0 B SELECT COUNT() FROM wygolde.ny_taxi_data.matTaxiDataPartClust -- estimated size: 0 B -- after research I found the following answer: -- BigQuery does not actually look at the data for a simple COUNT() query -- but it looks at the metadata catalogue which stored the row number -- into the catalogue during the creation of the materialized table -- so bigQuery does not look at the data but just at an entry in the catalogue. -- Note: This breaks if we use a filter though -- like: SELECT COUNT() FROM T WHERE X = 1 -- now bigQuery actually has to look at the data	1
SELECT count(*) FROM `zoomcamp.yellow_tripdata_2024`; It read 0 bytes (Bytes processed = 0B) This is because BigQuery keeps metadata about row counts for native tables. It doesn't actually scan the table to give you a total count.	1
From what I have seen, BigQuery dry run estimates to 0 bytes processed for this query. As to Why? A COUNT(*) in a materialized view of BigQuery scans 0 bytes because it uses metadata stored in the table's footer (specifically a row counts in Parquet footer metadata or BigQuery's very own snapshot metadata) rather than scanning the actual data. This occurs for fully aggregated materialized views or when the query is served directly from pre-computed query results. Queries that make BQ to scan data (relevant columns) which results in non-zero bytes which are: - DISTINCT - filtering conditions (WHERE) or selecting specific columns	1
Estimated bytes will be 0 because BigQuery uses table metadata rather than scanning actual data. The row count is stored as metadata when the table was created from the external table source.	1
The estimated bytes are very small (or 0 MB) because BigQuery uses metadata to compute row counts without scanning the full table.	1
0 bytes. Due to BigQuery using metadata instead of scanning data when evaluating COUNT(*).	1
It estimates 0B will be processed. This happens because row count is already present in the metadata of the materialized table and BigQuery picks that. This can also happen because we ran the same query in Question 1, and as a result BigQuery cached that result	1
SELECT count(*) FROM axial-trail-485514-p5.hmwk3dataset.yellow_taxi; This query will process 0 B when run. (BigQuery used a cached result for that identical query, it shows “0 B” to run — the engine will return the previous cached output instead of scanning the table again)	1
The estimated bytes is 0 B because the number of rows is already saved as metadata.	1
Due to the fact that the query result has been ran and is already cached.	1
Zero. Because BigQuery gets the count from the table metadata, not from actually scanning the table.	1
0B Because Big Query keeps row count in table metadata	1
`SELECT count(*)` query in BigQuery will read the entire table. The table is not partitioned or clustered, so all data is scanned.	1
0 Bytes. There are a few reasons: 1. Metadata vs data scans: For native tables, BigQuery constantly maintains a count of the total number of rows. When we ask for a simple count(), BigQuery’s optimizer doesn't bother looking at the actual data rows; it simply pulls the number from the table's metadata. 2. Columnar storage: BigQuery uses a columnar format (Capacitor). In a standard query, you are charged based on the amount of data in the columns you select. Because count() doesn't require reading any specific column values to give you a total tally, there is no data "processed" in the traditional sense. 3. Materialized vs external table: For external files (CSV, Parquet), BigQuery doesn't "own" the metadata, so it actually has to scan the files to count the rows, leading to a non-zero byte estimate.	1
It's estimated to be 0 byte because it will use metadata to answer this and does not need to scan through the dataset.	1
The estimated bytes will be very small (nearly 0MB or a few MB), because the materialized table is already pre-aggregated and BigQuery does not have to scan much data.	1
SELECT COUNT() FROM `kestra-sandbox-450522.dezoomcamp_hw3.yellow_taxi_materialized`; The query estimates 0 bytes to be read. BigQuery is able to answer a SELECT COUNT() query using table metadata only. Since the query does not apply any filters or require reading specific columns, BigQuery does not need to scan the underlying data. As a result, the estimated bytes processed is 0B.	1
BigQuery is highly optimized for performance and cost. For a simple COUNT(*) without any WHERE clauses or other operations that require reading actual data, BigQuery can often retrieve the row count directly from the table's metadata. This means it doesn't need to scan the physical data stored in the table, resulting in a 0-byte estimate for the query.	1
O bytes.	1
0 Bytes ,it did not go to the columnar storage to get the count , it read from metadata	1
Zero Bytes, or a minimal amount. A SELECT count(*) query from a materialized table in BigQuery will typically estimate that zero bytes will be read, or a minimal amount, because it can use precomputed statistics or read from the already computed and cached result (the materialized view itself).	1
0 Bytes - BigQuery stores metadata (that contains number of rows) of a materialized table in separate layer and updates it whenever there is any DML operation performed upon that table.	1
It returns 'This query will process 0 B when run' because it already knows this value from the table metadata.	1
SELECT COUNT() FROM `ny_taxi.yellow_tripdata_2024_non_partitioned`; Answer: 0 B Explanation: BigQuery maintains a summary of the table that includes the exact number of rows. Run the SELECT count() command simply retrieves this number from the summary instead of reading the actual data files. So no data is checked	1
0 B (zero bytes). Because BigQuery can get the count from table metadata without scanning any actual data rows.	1
Because the materialized table is NOT partitioned, BigQuery has to scan the entire table to count the rows.	1
When executing SELECT COUNT(*) FROM table in BigQuery, the processed bytes are 0 because BigQuery leverages metadata caching to directly return the total row count without scanning any actual data.	1
SELECT COUNT(*) FROM kestra-sandbox-485208.zoomcamp.yellow_tripdata_non_partitioned; BigQuery는 테이블에 데이터가 들어올 때마다 "이 테이블의 총 행(Row) 수는 몇 개다"라는 정보를 별도의 '메타데이터 저장소'에 자동으로 기록해두기 때문에 데이터 스캔이 불필요하다. 그로 인해 0바이트라는 예상치가 나온다.	1
0 MB because BigQuery already has the schema and the table details like number of rows	1
0B. Because BigQuery gets the row count directly from the metadata and does not scan rows.	1
When running a SELECT count(*) on a materialized table in BigQuery, the estimated bytes processed will be 0 B. Because BigQuery does not perform a Table Scan for this query.	1
0B because its using the metadata	1
This query will process 0 B when run. The result of this query is the number of rows in the given table. BigQuery stores this number as metadata, so there is no need to scan the entire table.	1
In GCP BigQuery prepare query: select count(*) from `zoomcamp-de-2026.bq_homework.yellow_tripdata_non_partitioned`; The estimated amount of data is 0B because this information could be taken from the table metadata since there is no additional filters	1
SELECT COUNT() FROM `de-zoomcamp-2026-484615.nytaxi.yellow_tripdata_2024_homework`; BigQuery stores the total row count of native (materialized) tables in its metadata. When executing a simple `COUNT()` without filters, BigQuery pulls this value directly from metadata instead of scanning the data columns, resulting in 0 bytes processed.	1
SELECT COUNT() FROM `zoomcamp.yellow_trip_data_regular` Estimated bytes read ~0MB COUNT() only needs row metadata, not the full table scan. BigQuery just looks at the row counter. COUNT(column) BigQuery has to open the column file and scan values.	1
This query will process 0 B when run. When running a SELECT count(*) on a materialized (native) table, BigQuery estimates that 0 bytes of data will be processed.	1
0 bytes because that information is stored in the table metadata in bigquery	1
The query scans the entire materialized table because COUNT(*) requires reading all rows to compute the result, resulting in a full table scan and a high number of bytes processed.	1
SELECT count (*) FROM `data-warehouse-485815.hw.yellow_materialized_table`	1
SELECT COUNT(*) FROM `de-zoomcamp-105558.zoomcamp.yellow_tripdata_2024`; -- 0 MB The estimation is zero MB because this information (row count) is materialized in BigQuery's metadata.	1
estimated bytes Typical result: 0 MB Reason: BigQuery uses table metadata/statistics for row count instead of scanning column data.	1
0 B , as the count is not dependent on the columns data ,it is not scanned from the metadata the result is obtained	1
0. The count of rows is readily available. Since we're counting "*" and not a specific column, there is no need to filter anything.	1
0 bytes: because BigQuery saves and is able to read metadata from tables, e.g. it has the total row count saved as metadata. In order to make it actually read the table and hence bytes will be used (and billed), a condition has to be entered, e.g.: select count(*) from `project-ef946217-bbe7-4f91-960.zoomcamp_de_hw3.yellow_taxi_data` where tpep_dropoff_datetime>='2024-03-01'	1
2.72 GB, because the query has to run through every column in the table to extract every entry, and they’re over 20 million records in the table.	1
0 MB because bigQuery using metadat to retur row, and not scanned that columns	1
0 bytes, because BigQuery stores pre-computed information about total number of rows in table's metadata.	1
SELECT COUNT(*) FROM `your-project-id.your-dataset.yellow_taxi_materialized`;	1
Since big query caches some metadata when a table is materialized, it simply outputs the cached data instead of reading the number of records all over again.	1
The estimated bytes processed shows zero since BigQuery can answer the query without scanning data, relying solely on metadata. In native (materialized) BigQuery tables, the row count is maintained within the table metadata.	1
SELECT COUNT() FROM `de-zoomcamp-485821.zoomcamp.yellow_tripdata_2024`; 0 MB because BigQuery uses the table’s metadata to calculate COUNT() on a materialized table, so it doesn’t need to scan the actual data.	1
This query will process 2.72 GB when run because it will be forced to run the whole table.	1
SELECT count() FROM `de-zoomcamp-12.homework3.yellow_tripdata_non_partitioned`; Based on the materialized table, the query will estimate 0 bytes to be read. The reason for this is that BigQuery maintains internal metadata for materialized tables, which includes the total row count. When you run a simple SELECT count() without any filters or calculations, BigQuery retrieves this number directly from its metadata storage instead of scanning the actual data files. Since no columns are physically read, the cost is zero bytes.	1
Because the database uses the table metadata and can read 0 bytes. That is why the database optimizer believes it can satisfy the request without scanning the actual table data rows.	1
SELECT COUNT(*) FROM `dtc-de-course-484819.dezoomcamp_hw3.yellow_taxi_materialized`; 0 bytes because BigQuery can use metadata to answer the query without scanning the entire table.	1
SELECT COUNT(*) FROM `my_project.nyc_taxi.yellow_taxi`; 0 MB read from metadata don't have to really read the data	1
It will estimate 0 bytes will be read because the materialized table has metadata that stores the information about it, so BigQuery will not go through any single row to count the total rows. Additionally, COUNT(*) doesn't require looking at the values of any specific column (unlike COUNT(VendorID), which would require scanning one column).	1
'SELECT count(*)' on a materialized (native) table using metadata only, without reading any table data.	1
This query will process 0 B when run as BigQuery stores row counts as table metadata.	1
`COUNT(*)` could be executed as metadata-only query (BigQuery already store this information)	1
BigQuery can compute it from table metadata without need to scan the table.	1
2.72gb	1
Bytes processed 0 B (results cached)	1
The estimated bytes will be 0 MB because BigQuery stores table metadata including the row count, so it doesn't need to scan any actual data to return COUNT(*).	1
0 B. Although a COUNT(*) query would normally require scanning all rows in a table, BigQuery can optimize this operation by using table metadata to determine the row count without reading the underlying column data. As a result, the estimated bytes processed is shown as 0, since no actual data blocks are scanned.	1
SELECT COUNT(*) FROM `arctic-thought-459809-d1.taxi.yellow_taxi_2024`; This query estimates that 0 bytes will be processed. I suppose the metadata already stores the row count	1
-- Q9. Write a `SELECT count()` query FROM the materialized table you created. -- How many bytes does it estimate will be read? Why? SELECT COUNT() FROM evident-axle-339820.nytaxi.yellow_tripdata_non_partitioned -- This query will process 0 B when run. -- Look at table info - Number of rows 20,332,093 ;	1
BigQuery estimates 0 bytes processed for COUNT(*) because it uses table metadata to compute the row count without scanning column data	1
This is a metadata operation for a materialized table. BigQuery stores row counts in metadata. Answer: 0 MB	1
0MB	1
20332093, It reads the full table because BigQuery must count all rows, and without filters there is no way to skip partitions or columns.	1
SELECT COUNT() as total_count FROM `project.dataset.yellow_tripdata`; Why? When running SELECT COUNT() on a table in BigQuery, it uses metadata-only scanning instead of scanning the actual table data.	1
0 bytes. Amount of rows is saved as metadata on table creation/update and BigQuery doesn't perform any actual queries under the hood to retrieve the amount of rows.	1
0MB - For a materialized (regular) table, BigQuery stores table metadata including row counts. When you run COUNT(*) without referencing any columns, BigQuery can return the result from metadata only.	1
0 B I did not know but chatgpt says BigQuery uses table metadata for COUNT(*) without filters, so no data is scanned.	1
0B, because its a simple operation and don't require to scan all table. Metadata are used for that	1
SELECT COUNT(*) FROM `w3-homework.your_dataset.yellow_taxi_materialized`; It is estimated to be 0MB	1
0 bytes because when you query "SELECT COUNT(*) FROM ...", instead of scan entire table again BigQuery just simple get the value of "num_rows" in metadata	1
SELECT count() FROM `de-zoomcamp-2026-486917.ny_taxi.yellow_tripdata`; 0B BigQuery stores metadata about the total number of rows in a table. When executing a SELECT count() query without any filters, BigQuery can return the result using this metadata instead of scanning the actual table data, resulting in 0 bytes processed.	1
Answer: BigQuery will likely estimate 0 bytes because it uses table metadata/statistics rather than scanning the actual data rows to get the count.	1
The number of bytes read will be 0 bytes. Reason: - This is a very important feature of BigQuery that illustrates the difference between reading data and reading metadata: - Storage metadata: For native (materialized) tables, BigQuery continuously maintains up-to-date statistics in its metadata, including the total number of rows (row_count). - Engine optimization: When you perform a COUNT(*) without a WHERE clause on a native table, BigQuery does not scan any columns. It simply queries its metadata to return the number instantly. - Cost: Since no data is actually “read” from disk, the query is free and the estimator displays 0 B.	1
0 B, because `SELECT COUNT(*)` for materialized views retrieves pre computed row count from metadata	1
0 B. When we create an external table, Big Query is not able to determine the rows or table size because the data resides in an external system such as GCS	1
It estimates 0 bytes. Row counts are stored as metadata in BigQuery. It can read this information directly.	1
Materialized tables: 0MB BigQuery maintains records within metadata, and queries with VendorIDs greater than zero result in bytes greater than 0MB.	1
I displays 0B processed as it reads no data, just queried the metadata.	1
SELECT COUNT(*) FROM `project-17f63bf9-2df3-4f7d-afd.zoomcamp.yellow_taxi_native`; Bytes processed 0 B Bytes billed 0 B	1
0 bytes is the estimate because BigQuery reads the metadata instead of processing the data of the table.	1
For materialized tables, Big query uses table metadata, and does not scan the actual data. So the estimated bytes processed may be zero	1
0 bytes since the table metadata can be used without scanning all the columns.	1
BigQuery using the Metadata of the table rather then scan the data.	1
SELECT COUNT() AS total_records FROM `project-63808ccf-cb8f-4204-919.ny_taxi.yellow_taxi_2024`; Estimated bytes read: 0 MB Why: BigQuery optimized the query using table metadata; no actual data scan is required for COUNT().	1
0. Because bigquery doesnt need to scan the data to count. It just reads the metadata for total row count.	1
Bytes processed 0 B Bytes billed 0 B Slot milliseconds 1164 BigQuery stores row count statistics in its metadata. For COUNT(*): It doesn’t scan the actual data. It reads precomputed metadata (like totalrows in INFORMATIONSCHEMA).	1
0 bytes as the number of rows is stored in meta-data for BQ, which GCP does not charge you to query.	1
0 - because it doesn't need to run the query it has the row count stored in meta data	1
0 Bytes, Since the query was cached due to earlier executions	1
This query will process 0 B when run. BigQuery can answer COUNT(*) using the table’s metadata (stored row count) instead of reading all rows, so it does not need to scan the data and the estimate is 0 bytes.	1
0B. count(*) doesn't need to read any specific column values. For a native table, BigQuery can often answer it using table/partition metadata (row counts) rather than scanning the underlying column data.	1
0 bytes because it uses metadata	1
SELECT COUNT(*) FROM materialized_table;	1
SELECT COUNT(*) FROM `dtc-de-course-485815.zoomcamp.yellow_tripdata_2024_non_partitioned`; It estimates that 0 B will be read. The reason is Biq Query retrieves the answer directly from the table metadata rather than scanning the actual data.	1
SELECT count(*) query in BigQuery for materialized table estimates 0 bytes read BigQuery stores row count information in the table metadata. For materialized tables (or immutable tables), this value is cached and updated automatically when data is loaded.	1
Zero. This is how Big Query works, it stores row counts as table metadata.	1
0 Bytes. Why? BigQuery keeps metadata about tables, including row counts. A simple COUNT(*) without filters retrieves this value from metadata rather than scanning the actual table storage.	1
It's estimate is 0. According to documentation: "A clustered table maintains the sort properties in the context of each operation that modifies it. Queries that filter or aggregate by the clustered columns only scan the relevant blocks based on the clustered columns, instead of the entire table or table partition. As a result, BigQuery might not be able to accurately estimate the bytes to be processed by the query or the query costs, but it attempts to reduce the total bytes at execution."	1
It estimates 0B read. This is because it can read size from metadata.	1
0 B BigQuery stores table metadata that includes the total number of rows The count is already precalculated in the metadata It doesn't need to scan any columns or rows to answer	1
select count() from `dtc-de-course-485707.ny_taxi_fazlan.external_yellow_tripdata`; 0B, No Scan Needed: When ask for a simple count(), BigQuery doesn't bother opening any of columnar files . It simply looks at the metadata, sees the row count, and returns it instantly. Cost: Since no data was read from the storage disks, the query is free.	1
0; Big Query read data directly from Metadata, no need to scan the real files.	1
0 Bytes. Explanation: For native BigQuery tables (materialized tables), the total row count is stored in the table's metadata. When executing a simple SELECT COUNT(*) without any filters, BigQuery retrieves this value directly from the metadata service instead of scanning the storage columns. Therefore, the estimated bytes processed is 0 B.	1
SELECT COUNT(*) scans almost no data because BigQuery uses table metadata.	1
0 Bytes, This is because bigquery answers directly from the table metadata without scanning any rows.	1
SELECT COUNT(*) FROM `peppy-caster-484310-c1.zoomcamp.yellow_tripdata_2024_ext` Read 0B, i think is related with metadata	1
select count(*) from `rides_dataset.yellow_taxi_regular`; 0 bytes bigquery stores number of rows as metadata, no need to count from table	1
0 Bytes, this query is estimated at 0 bytes because the result for a total row count is already cached within the metadata of the materialized table, since we are not checking for any specific column or filters BigQuery simply pulls this cached value	1
0 bytes. Becasue BigQuery can identify the materialized table, and when I need count(*) data, BigQuery will just check the metadata of this table without actually query it.	1
SELECT count(*) FROM dtc-de-course-486009.zoomcamp.yellow_tripdata_2024; BigQuery stores the row count in the table's metadata. So this query processed 0 bytes.	1
Materialized/regular tables store data in BigQuery storage, so a query that only needs row count doesn’t need to scan all columns. This results in fewer bytes scanned. The estimate for the query SELECT COUNT(*) FROM `ny_taxi.yellow_taxi` resulted in 0 Byte.	1
0 B. Because BigQuery is able to return the total row count of a native table for free because it doesn't actually scan your data to get the answer.	1
✅ Estimated bytes read ➡️ 0 MB The Reason is due BigQuery stores row count metadata for native tables COUNT(*) can be answered without scanning data So the query uses metadata only → no bytes processed	1
0 bytes because bigquery doesn't need to read the data to count rows, itt uses themetadata which already stores the row count for each partition ( so it sum up the numbers for all partitions )	1
~310 MB because COUNT(*) scans the full table	1
This query will process 0 B when run. This is because no column was selected, hence it scans only the row count and estimates the bytes read. This is only an estimate.	1
0 byte, It shows zero byte because materialized tables come with meta data which includes data like row count, thus there is no need to scan through the real data to get the row count, the value is rather read directly from the meta data.	1
0 bytes, Big Query check its own metadata instead of scanning the actual data.	1
0 MB BigQuery users table metadata to return row counts without scanning data	1
SELECT COUNT(*) FROM `project.dataset.yellow_taxi_materialized`; -- Estimated bytes: 0 B	1
0 bytes. BigQuery maintains internal metadata for each table, including the total row count. Since SELECT COUNT(*) with no WHERE clause doesn't need to read any actual column data, BigQuery resolves it directly from its cached metadata, resulting in 0 bytes processed.	1
0 Bytes. BigQuery saved Metadata so it does not need to read the table again to calculate the amount of rows.	1
0 bytes because BigQuery can answer COUNT(*) on a materialized table using metadata only, without scanning any column data.	1
-- This query will process 0 B when run SELECT COUNT(*) FROM `terra-77564.kestra_dataset.yellow_tripdata_parquet`; -- The reason that in this case it will use metadata for getting total number of records.	1
0 Bytes. Because BigQuery reads the table metadata for exact row counts on non-filtered queries, hence avoids a full table scan.	1
0 B BigQuery stores lots of meta data for each table, one of them is the "Total logical bytes 2.72 GB" So no need to for a scan	1
0b because BigQuery doesn't need to read any data; it is a metadata-only operation.	1
0 Bytes. BigQuery reports 0 B processed because COUNT(*) can be answered using table metadata only, without scanning any column data, and metadata reads are not billed	1
20332093	1
0 because the result is cached	1
0 Bytes, because use cache of the metadata of the table	1
0 bytes it avoid using the column and count directly the row	1
BigQuery keeps the row count in table metadata, so count(*) doesn't scan any data. It just looks up that number.	1
0 B When we run SELECT count(*), BigQuery doesn't need to scan any actual data (columns) to get the answer. It simply looks up the row count in the table's metadata and returns it instantly. Since no data columns were read, the estimated bytes processed is 0.	1
CREATE OR REPLACE TABLE `zoomcamp.yellow_taxi_trips_2024_partitioned_clustered` PARTITION BY DATE(tpep_dropoff_datetime) CLUSTER BY VendorID AS SELECT * FROM `zoomcamp.yellow_taxi_trips_2024`; 0 bytes estimated. BigQuery stores row count in internal metadata. For a simple COUNT(*) with no WHERE clause, it returns the count directly from metadata without scanning any table data.	1
0 BigQuery uses metadata and does not scan all columns to get the total number of records.	1
-- Count query SELECT count() FROM `taxi-rides-ny-485214.ny_taxi_bigquery_dataset.external_yellow_tripdata` BigQuery can retrieve COUNT() from table metadata without scanning actual data, resulting in 0 bytes processed. Here's why this happens: Metadata storage: BigQuery maintains metadata about each table, including the total number of rows. This information is stored separately from the actual data. No data scanning required: When you ask for COUNT(*) without any filtering conditions, BigQuery doesn't need to read through the actual table data—it simply looks up the pre-calculated row count in the metadata. Cost efficiency: Since no data is scanned, you're charged 0 bytes for this type of query, making it essentially free. This is different from queries with WHERE clauses or COUNT(DISTINCT column), which require scanning the actual data to filter or deduplicate values	1
SELECT COUNT() FROM `zoomcamp_hw3.yellow_tripdata_2024`; BigQuery shows: This query will process 0 B when run and still returned: 20332093 Why is it showing 0 B ? Because BigQuery can answer COUNT() using table metadata. For native (materialized) tables, BigQuery often stores the row count in metadata. So it does not need to scan any data blocks. This is why: - 0 bytes are read - but you still get the correct row count. This is expected behaviour - Our table is: zoomcamp_hw3.yellow_tripdata_2024 which is: - a native BigQuery table (not external) - not a view - not using any filters BigQuery optimizes: COUNT() → and answers it directly from metadata. Earlier we said: COUNT() usually scans the full table That is logically true, but in practice: BigQuery uses a metadata shortcut when possible. So in our case the correct explanation is: BigQuery is able to return the result of COUNT(*) from table metadata, therefore the query processes 0 bytes.	1
```sql SELECT COUNT() FROM `<project_name>.nytaxi.non_partitioned_hw3_yellow_tripdata` ; - Estimated: 0 B ``` A COUNT() without WHERE clause or filters reads no data blocks because BigQuery uses table metadata to return the exact row count instantly for materialized tables, without scanning partitions or clusters.	1
0 bytes. BigQuery can use metadata optimizations to return the row count without scanning any data, resulting in zero bytes processed.	1
Estimated Bytes: 0 B BigQuery maintains metadata about its native tables. When i run a SELECT count(*), BigQuery doesn't actually scan the rows; it simply reads the count from the table's metadata.	1
0 Bytes because BigQuery keeps metadata about tables, including the total row count. A simple SELECT COUNT(*) without any WHERE clause retrieves this value directly from the metadata service without scanning any actual table storage.	1
It shows 0 B when run. It reads no additional bytes, because it already knows the number of rows (stored internally in the table metadata)	1
It would be zero bytes. As bigquery maintains metadata, the given query requires total count without any other filter. So, bigquery can take it directly from metadata and will not process bytes for this.	1
0 B, Big Query can't estimate the bytes amount that it'll process in the query	1
0 bytes to process. This is because BiqQuery uses table metadata information. The `Number of rows` in the Storage info.	1
-- question 9 SELECT COUNT(*) FROM yellow_taxi_data_wk3.yellow_taxi_regular_table; -- Estimated bytes: 0 B	1
Query: SELECT COUNT() FROM `nytaxi.yellow_tripdata_2024`; Estimate: 0 MB Reason: BigQuery uses table metadata (statistics) to answer COUNT() without scanning actual data.	1
It estimates 0 B, because the information of the total row count is already stored in the table's metadata. If we were to add a filter it would need to scan the table and thus estimate more than 0 B.	1
0 Byte. Because bigquery stores meta data separately. It has total rows as one of its metadata. So no scanning is required.	1
Because there’s no filter, join, or column computation, BigQuery may not need to scan any data blocks, so the job reports 0 bytes processed.	1
Estimated bytes to be read: 0 MB Reason: BigQuery (and other modern analytical engines like Athena) maintains internal metadata for materialized tables. When a SELECT count(*) query is executed, the engine does not need to scan the actual rows within the data files. Instead, it retrieves the total row count directly from the table's statistics or the metadata layer. Since no data files are opened or processed, the estimated amount of data scanned is zero.	1
0 B — BigQuery can use table metadata to answer row-count queries without scanning table blocks, so bytes processed are shown as 0.	1
0 because the BQ will bring the answer from the table's metadata instead, no rows scanning required(except querying external table instead, that will be another case)	1
The query is estimated to read 0 bytes. This is because COUNT(*) is simply the count of total rows in the table, which is a statistic that is stored in the table's metadata. Hence, instead of needing to query the table itself, BigQuery can simply access the table's metadata to identify how many rows are in the table.	1
Answer : BigQuery dry run estimates 0 bytes processed for this query. Why? A COUNT(*) in a BigQuery materialized view (or table derived from Parquet) scans 0 bytes because BigQuery uses metadata stored in the table's footer (specifically row counts in Parquet footer metadata or BigQuery's own snapshot metadata) rather than scanning the actual data. This occurs for fully aggregated materialized views or when the query is served directly from pre-computed query results. (Metadata Optimization) Queries that make BQ to scan data (relevant columns) which results in non-zero bytes: - DISTINCT - filtering conditions (WHERE) or selecting specific columns	1
0 B. 0 Mb. Because for a native materialized / physical table, BigQuery already stores: * table metadata * row count statistics * storage statistics So for this query BigQuery does NOT need to scan the data blocks. Instead it: * reads metadata * uses internal statistics * returns the count	1
Estimated bytes processed: 1.09 GB Why: SELECT COUNT(*) on your non-partitioned/materialized table (indra-gcp-lab.zoomcamphw3.yellow_taxi) has no filter, so BigQuery must scan essentially the entire table to count all rows. Since it’s columnar, it mainly reads what’s needed for the count, but it still has to read across all row groups/metadata for the full dataset—so the estimate is about the full table scan size.	1
0 bytes BigQuery can answer COUNT(*) for native tables using metadata/statistics, so it does not need to scan table data blocks.	1
SELECT count(*) FROM yellow_taxi	1
SELECT count(*) FROM `kestra-sandbox-486123.rides_dataset.rides`; it generates 0 bytes because the query only read the meatadata, it doesn't need read the data or the columns	1
0B - Because bigquery store the metadata of table, including the number of rows of table. When estimate the query, BQ use the metadata instead of scanning the actual data.	1
0 Bytes When you run SELECT count(*) on a native BigQuery table (that is not external), BigQuery retrieves the row count from the table's metadata rather than scanning the actual data rows.	1
Estimate is 0 because BigQuery does not need to read any table data for COUNT(*). It uses the table metadata as no column data is read.	1
```sql SELECT COUNT() FROM `mystic-airway-484017-d6.zoomcamp.yellow_tripdata_materialized`; ``` Answer: `This query will process 0 B when run.`* BigQuery stores table metadata that include the total row count, so for COUNT() without a WHERE clause, BigQuery can simply return the row count from metadata without reading any actual data and since COUNT() doesn't need to read any specific columns, and there's no filtering, BigQuery uses the stored metadata.	1
SELECT COUNT(*) FROM `mythic-altar-485103-v8.my_zoomcamp_bigdataset.yellow_taxi`; Estimated value is 0B because this is a metadata only query. This query does not have any filter need so it gets this information from metadata itself and does not need to run the real query on the table. So it is 0B	1
SELECT COUNT(*) scans the entire table, so the estimated bytes read are close to the table’s total size. This is because counting rows requires reading all records and there is no partition filter to reduce the scan.	1
When running a SELECT count() on a materialized table in BigQuery, the estimated bytes processed will be 0 B. Because BigQuery does not perform a Table Scan for this query. BigQuery is a modern data warehouse that maintains extensive Metadata for all its native tables. Metadata is essentially "data about the data" that is stored separately from the actual rows. - Metadata Lookup: For a simple count() without any filters (WHERE clauses), BigQuery simply reads the row_count property from the table's metadata. - No Column Access: Since you aren't filtering or selecting specific column values, the execution engine doesn't need to open or scan the columnar storage files (Capacitor). - Efficiency: This makes the operation nearly instantaneous and completely free of charge in terms of "bytes processed".	1
Estimated Bytes: 0 B (Zero Bytes). Because BigQuery stores the total row count at metadata for native (materialized) tables. So, when a count query without any WHERE clause is run, BigQuery simply read this value from metadata instead of scanning the table.	1
0 B, COUNT(*) on a materialized table can be answered from metadata/statistics without scanning the table’s columns.	1
0 bytes, the total row count is stored as a piece of metadata	1
0 byte. Bigquery could use metadata to count row numbers without any bytes processed.	1
It estimates 0 bytes to be read. This is because counting the number of rows doesn't actually involve processing the rows. BigQuery can easily look at the table's metadata to get that info.	1
0B COUNT(*) does not need to read any actual column data Instead, BigQuery can rely on table metadata Because this is a materialized (physical) table, the row count is already known and stable	1
This query will process 0 B when run. Because of the metadata stored in BigQuery for materialized tables, it knows the total number of records without needing to scan the actual data along with other statistics(like size, number of columns, categories etc.)	1
This query will process 0 B when run. I understand that BQ not read all the data for count(*), it's read from metadata	1
Bytes scanned is 0B. The reason behind this is that the metadata for the table already has the row count, so no bytes need to be processed.	1
0 bytes processed because BigQuery can answer it from table metadata.	1
0MB. Because the count is already stored in the metadata	1
Bytes estimate is 0, because BigQuery use metadata for 'answering' the query. In contrast, when I've tried with vendor_id = 6, it estimated 155.12.	1
0b, because the data is already cashed.	1
The estimate is 0B when run. This happens because BigQuery uses the table metadata for that query. It doesn’t need to scan any data blocks.	1
0B It’s due to Metadata Optimization: Pre-calculated: BigQuery stores the total row count in the table's metadata. No Scan: COUNT(*) pulls this number directly without reading any actual data rows. Result: 0 bytes processed = Free query.	1
0 Bytes - meta data	1
SELECT COUNT(*) FROM nytaxi.yellow_2024_materialized; Bytes: 0 bytes - because BigQuery save metadata count separately.	1
BigQuery stores metadata about tables, When you run COUNT(*) (without a WHERE clause), it doesn’t scan actual data and read from metadata.	1
Ans: 0 Bytes. Explanation: BigQuery estimates 0 bytes because `COUNT()` is a metadata-only operation: - BigQuery stores table metadata including row count - The query can be answered using metadata alone without scanning any actual data - This makes `COUNT()` extremely fast and cost-free - If you used `COUNT(column_name)`, it would need to scan that column to count non-NULL values	1
It shows zero bytes, and that is because gcp reads the metadata directly, instead of read the whole table.	1
It will process 0B. This is because table total rows is held in BQ's metadata.	1
SELECT count() FROM `taxi-rides-ny.nytaxi.native_yellow_tripdata`; 0 Bytes. This is because COUNT() on a non-external table retrieves metadata statistics without scanning the actual data	1
0. The row count is stored in the metadata of the table.	1
0 Bytes Why? Metadata Storage: BigQuery maintains a set of metadata for every native table it stores. This metadata includes the exact number of rows, the creation time, the physical size, and other statistics. No Column Scanning: Since a count(*) doesn't require looking at the actual data values inside any specific column, BigQuery simply pulls the "total rows" value from its internal metadata instead of opening and scanning the data blocks on disk. Optimization: Because no data files are actually read, the "Bytes Processed" is zero, making the query both instant and free.	1
SELECT COUNT(*) FROM yellow_taxi_native; 0 MB	1
0 B because a simple operation like count is already found in the metadata. No need to go through the column and count since it is in the metadata after table is materialized.	1
SELECT COUNT(*) FROM `datatalks-de-zoomcamp-2026.ny_taxi_data.yellow_tripdata_2024_01_06`; Answer: zero bytes; the engine uses the table metadata.	1
0 MB (uses metadata)	1
The estimated usage shows 0 bytes because BigQuery already knows exactly how many rows were added during the table creation process and stores the total count in its metadata.	1
SELECT COUNT(*) FROM `de-hw3-yellow-taxi.nyc__yellow_taxi.yellow_taxi_replica`; "0 bytes (results cached)" because BigQuery didn't re-scan the data due to result caching.	1
Estimates bytes read Almost the entire table size (hundreds of MB or GB depending on your table)	1
SELECT COUNT(*) as total_rows FROM `de-zoomcamp-module3-486909.trips_data_all.yellow_tripdata`; -- answer: 0 B	1
it states 0 MB, but I think that this is because it can not estimate the size of the query because it has to analyze all the rows of the tables the amount of times as it has columns	1
0 bytes. BigQuery retrieves the count from table metadata for simple SELECT count(*) queries on materialized tables.	1
select count(*) FROM `symmetric-ion-480511-d2.taxi_rides_ny.yellow_tripdata` This query will process 0 B when run. This is the amount meta data is scanned.	1
The estimate number of bytes is 0 B and the reason is that with materialized tables, BigQuery already maintains the count of records as part of the table metadata. If we added a filter, we'd obtain an amout of bytes different than zero. For instance, the estimate of processed bytes for this other query is 155.12 MB. SELECT COUNT(*) FROM zoomcamp.yellow_tripdata_parquet WHERE VendorID = 2	1
This query will process 0 B when run. Because when running a COUNT(*) over a materialized (native) table on bigquery it retrieves the data from the metadata and doesn't need to scan the table.	1
-0 Bytes - BigQuery can read the internal metadata for native tables	1
SELECT COUNT(*) escaneia a tabela inteira, lê todos os dados.	1
0 Bytes. The `count(*)` value is an aggregation served entirely from the table metadata statistics as opposed to needing to read the table itself.	1
0 bytes. BigQuery stores table metadata, including row counts, so it doesn't need to scan any data for a simple `COUNT(*)`	1
The estimate reads 0 bytes. This is because when you run a select * from table, BigQuery sees that you are not asking for filtered or specific rows. Thereby not processing data.	1
SELECT COUNT(*) FROM `neat-phoenix-431310-j3.yellow_taxi.yellow_taxi_2024`;	1
0B because it will read from metadata.	1
This query will process 0 B when run, because BigQuery is using the query result cache.	1
0 Bytes. Probably because the query would just produce the number of rows which is metadata stored by BigQuery so can return metadata directly.	1
0 Byte because Bigquery has a metadata so when count(*) it will be read in metadata that have a row count already.	1
It took 0 bytes to be read. BigQuery has stored the simple query results and keeps the results on disk. Simple queries include the count(*). Since this is precomputed and stored in the materialized table, BigQuery does not scan/read the table for this query, and BigQuery just retrieves this result.	1
Using table metadata to return row counts without scanning data.	1
0, for materialized table info containing number of rows is already exist at creating	1
It estimated 0 bytes because the number of rows is stored in the metadata of the materialized view in BigQuery.	1
LLM Because BigQuery does not have to read any of the table’s column data to answer that particular question. The engine can return an exact row-count by reading only the table’s stored metadata, so the amount of “bytes processed” is reported—and billed—as 0 MB.	1
select count() from `bigquery-kat.ny_taxi_2024.yellow_tripdata Estimation: This query will process 0 B when run. Explain: COUNT() on a BigQuery table is free because BigQuery answers it using metadata, not data scans.	1
Estimated data processed is 2.72 GB. It is huge because the materialized table is not partitioned and clustered. Then, the reason why it is so big to process is that I am calling all columns. BigQuery is columnar based and serverless database system, so, more columns I call, more data it is processed, and more costs emerge.	1
-- q9 -- from 'external table' pointing to GCS parquet files -- copy/materialise the data into a materialised table CREATE OR REPLACE TABLE zoomcamp.yellow_tripdata_materialized_2024_01to06 AS ( SELECT * FROM zoomcamp.yellow_tripdata_external_2024_01to06 ); -- Duration 7 sec -- Bytes processed 2.72 GB -- Bytes billed 2.72 GB -- Slot milliseconds 139368 -- This query will process 0 B when run. -- 0B because count of records is in table's metadata -- no need to read any records/data SELECT COUNT(*) FROM zoomcamp.yellow_tripdata_materialized_2024_01to06; -- This query will process 0 B when run. SELECT COUNT(1) FROM zoomcamp.yellow_tripdata_materialized_2024_01to06; -- This would scan ALL data (full table scan) -- when counting on a specific col -- cuz we counts only non-NULL values in that specific column -- This query will process 155.12 MB when run. SELECT COUNT(PULocationID) FROM zoomcamp.yellow_tripdata_materialized_2024_01to06;	1
0 bytes. Because this table is a materialized table that has row-count metadata and it is not being filtered by any column.	1
SELECT COUNT(*) FROM `poetic-genius-486912-k5.ny_taxi.yellow_taxi_2024`; It shows 0 B because BigQuery returned the result from cached query results. To see the actual bytes processed, cached results must be disabled.	1
0 because BQ uses metadata to get this info.	1
select count() from zoomcamp.yellow_taxi_part; Returns 0 bytes because BigQuery already knows how many rows are in the table. When you run COUNT() on a materialized (native) table, BigQuery just checks its internal metadata instead of reading all the data again. So it doesn’t need to scan the table, and the estimated bytes read are basically zero.	1
The estimated bytes read is 0B. Since the query just read from metadata, instead of scanning the full table.	1
The estimate number of bytes is 0 B and the reason is that with materialized tables, BigQuery already maintains the count of records as part of the table metadata. If we added a filter, we'd obtain an amout of bytes different than zero. For instance, the estimate of processed bytes for this other query is 155.12 MB.	1
0 B (Zero Bytes) This occurs because of BigQuery's internal storage architecture and metadata management: Metadata Storage: For native (materialized) tables, BigQuery maintains a set of metadata that includes the exact row count. This metadata is updated whenever data is loaded, appended, or deleted. No Data Scan Required: When you run a simple SELECT count(*) without any WHERE clauses or filters, the BigQuery optimizer realizes it doesn't need to look at the actual data rows. Instead, it simply fetches the pre-calculated row count directly from the table's metadata. Efficiency: Since no columns are actually read from the physical storage (the Capacitor files), the "Bytes Processed" is reported as 0.	1
The estimate is 0 B and that's because bigquery will utilize the metadata it has stored about the table instead of doing a full table scan like other data warehouses.	1
587 MB	1
It gives: This query will process 0 B when run. I guess it's already in the table detail so it does not need to actually run the query to find out?	1
2.72GB, because that's the size of all the data stored in the table	1
-- Answer: 0B. Because; BigQuery stores the total number of rows in the table metadata. We run Select count() don't scan table. Directly read to metadata the this number. So, the cost is 0. SELECT count() FROM `ny_taxi.yellow_tripdata_non_partitioned`;	1
0 bytes will be read because the table was optimized (partitioned and clustered are known) so count can be computed from the table metadata, and BQ doesn't need to scan the table	1
Estimated bytes read: ~0 MB Why: BigQuery uses table metadata for count(*) and does not scan actual column data.	1
It is estimated to read 0 bytes because it has the row count stored in the table metadata so it doesn't need to read any data in the table.	1
0, because this information is stored as metadata already.	1
-- 0 MB select count() from `data-engineering-module-03.ny_taxi.yellow_taxi`; The count() only uses metadata to get the count of records, so it does not need to read the actual data.	1
0 bytes, because BigQuery uses table metadata to compute COUNT() on native tables without scanning the actual data.	1
0 bytes. Because BigQuery stores table metadata internally. It will not scan anything for count(*)	1
This query will process 0 B when run because BigQuery can satisfy the query without scanning storage. # Partioned and Clustered Table 26.84MiB SELECT COUNT(*) FROM kestra-sandbox-485712.zoomcamp.yellow_tripdata_01_to_06_2024_partitioned_clustered;	1
It estimates 0 bytes. This is because BigQuery is a columnar database and it estimates the bytes based on the size of the records scanned for a given column, since * represents no specific column, no size could be estimated.	1
This command shows processing 0 Byte because Bigquery is a columnar storage. It will read the row numbers from metadata instead of scanning any columns in the table.	1
SELECT COUNT(*) FROM `dataex-486105.ny_taxi.yellow_taxi_partitioned_clustered`; This query costs 0 bytes because BigQuery doesn't need to scan the table to produce the number of rows of a table.	1
0B. BigQuery utilizes metadata-only lookups to fetch row counts without scanning actual records.	1
SELECT COUNT(*) FROM taxi.yellow_taxi_data; 0B if this exact query is ran before due to query caching enabled.	1
0, because the number of records is within the metadata	1
SELECT COUNT(*) FROM `dezoomcamp-483523.module_3_hw.yellow_tripdata`; Reason: BigQuery retrieves row count directly from table metadata without scanning actual data, so 0 bytes are processed.	1
0 B COUNT(*) does not need to scan any columns, however BigQuery can answer this using table metadata and none column data is read from storage	1
Answer: 0 Bytes. Why: I checked that columnar databases like BigQuery (and Snowflake) keep the row count in metadata. So running count(*) reads from metadata instead of scanning the table rows.	1
BigQuery estimates that 0 B will be scanned because the query asks to return a total row count of the table. Since the total row count of a materialised table is stored in its metadata, there is no need to scan any data in order to return it.	1
The estimated of data is 0. This happen because Bigquery is a columnar data warehouse. it will not 0 if I attach the column in query.	1
0 bytes. In a materialized view, the total table size is already calculated, so it can return the count from the table metadata without querying the data directly.	1
2.72 GB	1
How many bytes does it estimate will be read? A: This query will process 0 B when run. Why? A: BigQuery caches query results to improve performance and reduce costs. When you run a query in BigQuery—as I did in Question 1—the results are cached for 24 hours by default. Running the same query again makes BigQuery retrieve the results from the cache instead of reprocessing the entire query.	1
```sql SELECT count(*) FROM `kestra-sandbox-485717.zoomcamp.yellow_tripdata_non_partitioned`; ``` Answer: `0 B`. BigQuery stores table metadata so there's no need to scan the whole table.	1
Answer: 0 MB. Analysis: Probably because BQ already has storage info which covers the total rows of a table. Therefore, this query will always fetch that metadata instead of scanning all over the table.	1
select count() from `nytaxi.nycity_taxi_yellow_non_partitioned`; select count() from `nytaxi.nycity_taxi_yellow_partitioned_clustered`; BigQuery can retrieve this information from the stored metadata without needing to scan the actual data in the table's storage.	1
SELECT COUNT(*) FROM `aiagentsintensive.dezoomcamp_hw3.yellow_taxi_materialized`; -- Estimated: 0 bytes	1
The estimated number of bytes is 0 B, and the reason is that with materialized tables, BigQuery already maintains the count of records as part of the table metadata. If we added a filter, we'd obtain an amount of bytes different than zero. For instance, the estimate of processed bytes for this other query is 155.12 MB.	1
```sql -- question 9 SELECT count(*) FROM dtc-zoomcamp-2026.nytaxi.yellow_tripdata_2024_hw; ``` It reads no bytes at all because this information is already known since the table creation. It's just the number of rows in the table and it's stored in the metadata of the table.	1
SQL query:* ```sql SELECT COUNT() FROM `de-zoomcamp-2026-486014.de_zoomcamp_yellow_homework_03_dataset.yellow_taxi`; --> 0 Mo ``` <p>BigQuery automatically stores the total row count in the metadata of its regular tables. Therefore, for a COUNT() without any filter, it can answer directly from this metadata without reading any physical data, which explains the 0 MB processing estimate.</p>	1
This results in 0 bytes processed because BigQuery maintains metadata about each table, including the total row count. Therefore, no table data is scanned to return the results of this query. On the other hand, if any columns are specified in the count, BQ would need to scan data (check for NULLs in that column) to return the appropriate results.	1
SELECT count(*) FROM zoomcamp-485516.yellow_taxi.yellow_tripdata_2024 -- 0MB -- BigQuery maintains table metadata, so it doesn't scan the actual data — it just reads the stored row count from metadata.	1
The Estimate: 0 bytes BigQuery is a highly optimized storage engine. For Materialized Tables (native tables), BigQuery maintains a set of metadata that tracks table statistics, including the total row count.	1
0 Bytes Why ? as we created "materialized" the table, The query engine created a metadata " data about data " where it save some major information about the data such as size, row count, schema .. etc	1
SELECT count(*) FROM `your_project.your_dataset.yellow_tripdata_2024`; 0 bytes. BigQuery stores the row count in the table's metadata, so it doesn't need to scan any columns for a simple count() query	1
I got a 0B message. I imagine this is because the result is cached.	1
0, it can't estimate, data resides in another storage, in GCP bucker	1
It will read 0 bytes, because the materialiced table is stored inside Bigquery. Bigquery answer using his internal metadata and storage statistics, so he doesnt have to re-read data. Job ID 448608:europe-west3.bquxjob_42992ee4_19c324ae231 User jgarcianagy@gmail.com Location europe-west3 Creation time Feb 6, 2026, 10:31:34 AM UTC+1 Start time Feb 6, 2026, 10:31:34 AM UTC+1 End time Feb 6, 2026, 10:31:34 AM UTC+1 Duration 0 sec Bytes processed 0 B Bytes billed 0 B Slot milliseconds 819 Job priority INTERACTIVE Use legacy SQL false	1
BigQuery can compute COUNT(*) using table metadata without scanning the underlying data, so the estimated bytes processed is 0 B	1
0B. BigQuery answers COUNT(*) by reading only the table metadata (such as row counts) without scanning the actual data blocks, so the estimated bytes read is 0.	1
0 B.	1
0B. Since the number of rows is part of the metadata for the materialized tables BigQuery does not need to execute the query at all. Instead it simply provides the value in the metadata.	1
BigQuery maintains metadata for managed tables (like row count). A simple COUNT(*) query without a WHERE clause or JOINs can be resolved entirely from this metadata without scanning any columns in the table, resulting in zero bytes processed.	1
Big Query 0B estimate is just a UI artifact.	1
0 B becasue for COUNT(*) bigquery doesn't read any rows, instead it reads the number of rows from the table's metadata.	1
0 bytes, because BigQuery retrieves this value from the table metadata	1
SELECT COUNT() FROM `ny_taxi.yellow_tripdata_external`; estimates that the query will process 0 MB when run because this is an external table, BigQuery can use file metadata (not data scans) to compute COUNT(), so the estimated bytes processed is 0 MB.	1
This query will process 0 B when run. BigQuery stores table metadata, including the row count, for materialized tables, which is being used to get the result of such query.	1
BigQuery (and many warehouses) keeps a "Metadata Cache." It knows the total row count of a table without needing to read the actual data rows.	1
0 MB Because materialized views pre-compute and cache results. COUNT(*) query is already aggregated in the materialized view's metadata, so it requires minimal to no scanning of the actual data.	1
0 MB This behavior is part of BigQuery's cost management and performance optimization, as scanning entire large tables for a simple row count would be resource-intensive and slow	1
# Homework 3 Question 9 # count() read 0 B because it has information from table metadata or information_schema already select count() from `zoomcamp-486023.zoomcamp.yellow_tripdata_2024_partition_cluster`;	1
Answer: 0 byte ,BigQuery computes COUNT(*) using table metadata for materialized tables. No column data is scanned, resulting in zero bytes processed.	1
Running SELECT count(*) on a native table results in 0 bytes processed. This is because BigQuery retrieves the row count from the table's metadata (a pre-calculated value) rather than scanning the actual data rows.	1
0, because it reads it from metadata	1
Excuse me, I don't have free access to Google Cloud so I worked on my local pc using localstack. I used s3 instead of gcs and duckdb insted of bigtable, so i cannot answer on this question.	1
0 bytes.	1
BigQuery estimates 0 bytes will be read. BigQuery maintains internal metadata statistics on every table, including exact row counts updated periodically (usually within minutes of changes). For COUNT(), the engine uses this metadata directly, avoiding any data scan-no slots consumed, instant execution. Partitioning and clustering don't affect COUNT() since no filter or grouping prunes data; metadata suffices regardless. In the query editor, the slot usage shows "0B scanned" before running	1
0 byte. Because BigQuery answers `COUNT(*)` using table metadata instead of scanning the table data.	1
select count () from dataset.materialized_table; ~155 MB because COUNT() needs to scan the entire table.	1
SELECT count(*) FROM `dezoomcampkestra.zoomcamp.yellow_tripdata_non_partitioned`;	1
SELECT COUNT(*) FROM `data-engineering-course-486123.ny_taxi_dataset_homework3.table_materialized`;	1
0MB. Because Big Query uses Caching and we have already ran this query to answer question 1 so it has been cached.	1
0B. BigQuery knows the number of rows without reading all columns.	1
Maybe because the count is retrieved from the metadata	1
I ran SELECT COUNT(fare_amount) on the materialized table yellow_taxi. The estimated bytes processed was 155.12 MB. This is because BigQuery had to scan the fare_amount column to count all non-NULL values. Unlike COUNT(*), which can sometimes use metadata to get the row count, COUNT(column) requires reading the column data, so more bytes are processed.	1
SELECT count() FROM `project_id.dataset_id.yellow_tripdata_2024`; The estimated bytes read is 0 MB because BigQuery uses stored metadata for native tables to answer COUNT(*) queries without scanning the underlying data.	1
0B, because the row count of the table is saved as metadata	1
0 bytes. It is because it will read the number of rows from the metadata instead of counting the actual rows in the table.	1
0B. The data is fetched from metadata of the materialized bigquery table	1
0Bytes	1
0 bytes. COUNT(*) is free (0 MB) because BigQuery answers it from table metadata.	1
The query I wrote is the following: ```sql SELECT COUNT() FROM `module-3-486600.ny_taxi_data_2024.yellow_tripdata_non_partitioned` ``` BQ estimates 0 bytes will be read. The reason for this is because BQ knows the number of rows within the source table itself, and so simply returns the value stored within the table's metadata as opposed to pulling in the table and doing the count itself. This can be proven by adding a random WHERE clause: ```sql SELECT COUNT() FROM `module-3-486600.ny_taxi_data_2024.yellow_tripdata_non_partitioned` WHERE VendorID = 2 ``` The prediction for reading this table now is that 155.12 MB will be read. This is due to the fact that the count of rows where VendorID = 2 is NOT stored within the table's metadata, and so BQ will actually need to load in the data and query it in order to provide us with the count.	1
0B Because BigQuery must scan all the columns in the dataset. It does not mantain a metadata with the information of the size of table.	1
It stores data by columns and since we select everything it can't estimate how much data will be read	1
0 B because this value is already known based on the table's metadata storage info which can be accessed in the table details tab.	1
Bytes processed 2.72 GB the query scan all table and read all columns, for this reason amount of processed bytes is very high.	1
SELECT COUNT(*) FROM your_materialized_table; BigQuery only reads metadata, not entire data tables.	1
This query will process 0 B when run. Because when retrieving all rows, instead of reading row by row, it directly gets the metadata of the table. So no scanning really happens.	1
SELECT COUNT(*) FROM `poised-beach-485617-n9.zoomcamp.yellow_tripdata_2024_h1`; This query will process 0 B when run.	1
This query will process 0 B when run because this information is already available in the table's meta, so it will just provide you the number of total rows.	1
Because in BigQuery, COUNT(*) can be answered using table metadata only. BigQuery stores the total number of rows for tables, including materialized tables, so the query planner does not need to scan any actual table data or read any columns. Since a materialized table is a fixed snapshot with known statistics, the row count is already available. As a result, no data blocks are scanned and the estimated bytes processed is 0 bytes.	1
0 bytes. BigQuery stores table metadata, including the row count. A SELECT COUNT(*) query doesn't need to scan any actual data — it returns the result directly from the table's internal metadata.	1
Estimation is 0B. BigQuery stores row counts in metadata for each storage block of a table.For a plain COUNT(*) (without any filters, no column references), it doesn’t need to read any actual column data.	1
0 B because BigQuery can just look into the metadata of the table since there are no filters applied.	1
SELECT count() FROM taxi-rides-ny-486415.Mod3HW.materialized_yellow_tripdata; Estimated: 0 B. This is because, BigQuery stores row counts for every table internally in meta data. When we do "SELECT count() query" it will not fetch any rows from the table. It will just read row count from the metadata of the table.	1
0, casue it directly read from Metadata	1
Bigquery (and many other databases for that matter) track table statistics. Because of this, this simple count is not actually querying any data at all. It is retrieving its internal statistics.	1
SELECT COUNT(*) FROM `zoomcamp03.yellowtaxi2024`; 0 bytes. It uses metadata and doesn't need to scan the table	1
Estimated Bytes: 0 B Reasoning: BigQuery maintains metadata (storage statistics) for all native materialized tables. This metadata includes the total row count for the table. When a query performs a naked SELECT count(*) without any filters, the execution engine retrieves this value directly from the metadata layer instead of scanning the actual data columns. Consequently, the estimated and actual bytes processed are zero. Key Constraints: No Filters: This optimization only triggers if there is no WHERE clause. Adding a filter (e.g., WHERE fare_amount = 0) forces BigQuery to scan the specific column to evaluate the condition, resulting in non-zero bytes processed. External Tables: This behavior typically does not apply to External Tables. Since the files reside in a GCP Bucket (GCS), BigQuery does not have the same level of real-time metadata control. It may need to read the Parquet file footers to determine the row count, which might show as "0 B" in the estimator but will actually consume Slot milliseconds during execution.	1
"This query will process 0 B when run." It will not read any bites because this information is already available in the table's schema.	1
select count(*) from module-3-bigquery-486618.ny_taxi.yellow_trips_2024_non_partitioned; bytes read will be 0 as BigQuery is a columnar database, and it only scans the specific columns requested in the query.	1
0 bytes. BigQuery maintains metadata for native (materialized) tables, including row counts. When executing a SELECT COUNT(*) query, BigQuery can directly read the row count from its metadata without scanning the table or columns, resulting in 0 bytes processed.	1
0 Bytes. Since: For a native (materialized) table, BigQuery stores the total number of rows in the table's metadata. A simple SELECT count(*) query reads this value directly from the metadata statistics without scanning any of the actual data in storage.	1
It estimates 0 bytes. This happens because BigQuery uses a metadata-only operation to retrieve the row count for the table, so it does not need to scan the actual data.	1
0, because it uses the internal metadata of the table	1
The COUNT(*) query reads 0 bytes because BigQuery can return the total row count using table metadata without scanning any column data. Answer: 0b	1
The total number of rows for the table is stored in storage metadata so that query engine doesn't have to run expansive count operations every time.	1
Estimated Bytes: 0 MB in 0.1s BigQuery stores the total row count for native tables in its metadata. it retrieve this information without scanning the rows	1
Query: SELECT count() FROM awesome-icon-484918-n5.ny_taxi.yellow_tripdata_non_partitioned; Estimated query size: 0 B Why? BigQuery maintains very detailed metadata in the background for each table. Basic information like the total number of rows in the table is readily available in this metadata. When we type SELECT count() (and don't use any WHERE filter), instead of counting millions of rows one by one, BigQuery reads that single number from the metadata file and returns it instantly.	1
SELECT COUNT(*) FROM `abiding-splicer-462011-a4.ny_taxi.external_yellow_tripdata_2024`; I believe because BigQuery holds metadata regarding this table, and since there is no filtering, BiqQuery can read directly from this metadata to look up the number of rows without the need to actually scan all or part of the table.	1
0 Bytes. Because it looks at the table statistics - the metadata.	1
0, since it's known in the metadata	1
SELECT COUNT(*) as total_count FROM `de-zoomcamp-2025-12345.zoomcamp.yellow_taxi_materialized`;	1
0 bytes, the database doesn't need to scan any actual data, it just returns the pre-computed row count from the metadata.	1
The estimated bytes processed is approximately the size of the entire table, because COUNT(*) requires a full table scan and BigQuery needs to read all rows to count the total number of records.	1
- 0B - Reason: BigQuery uses metadata for `COUNT(*)` queries without scanning actual data	1
0 Because it's pre-requested and does not actually get any data	1
0 kb, BigQuery is a columnar database, and since count(*) does not require scanning actual data columns but only metadata, the query scans a minimal amount of data	1
This query will process 0 B when run. Big Query can get the row count from the metadata since this is a native table and we are not using any filtering to force scanning the data	1
SELECT COUNT() FROM `case-study-53427.zoomcamp.yellow_taxi_materialized_table`; The count() query scans the entire table because it needs to count all rows. Since the table is not partitioned or clustered, BigQuery must read all underlying data, which results in a higher estimated number of bytes processe	1
0 B, BigQuery returned 0 B processed because it used table metadata to retrieve the total row count without scanning the underlying data files. For simple COUNT(*) queries without filters, BigQuery can avoid a full table scan.	1
SELECT COUNT(*) FROM `taxi-rides-ny-bq.dezoomcamp_hw3_bq.yellow_tripdata_2024`; Answer:0 MB (or 0 Bytes) BigQuery uses table metadata to return the count without scanning any actual data.	1
The estimated bytes read is 0 B because BigQuery retrieves the row count from the table metadata, not by scanning the actual data.	1
0MB (BigQuery stores metadata about row counts and not the actual rows)	1
0 bytes read. Because BigQuery stores the total number of rows (row count) in the native (materialised) table metadata. When you run a SELECT count(*) without filters on a table of this type, BigQuery does not need to scan any physical columns or rows; it simply reads that single value from the metadata, which does not involve any data processing costs.	1
The estimated bytes read is 0 bytes because BigQuery can answer COUNT(*) queries using table metadata without scanning the actual data in a materialized table.	1
0B. Because BQ can answer count(*) by using metadata only. Without having to scan the actual table.	1
The query reads 0 GB because BigQuery uses metadata to compute COUNT(*) on the materialized table, so no data scan is required.	1
It is estimated to read 0 bytes because BigQuery doesn't need to scan any actual column data to count rows — it can get the row count from the table's metadata/partition info alone.	1
SELECT COUNT () FROM ammar-zoomcamp.zoomcamp_hw3.yellow_tripdata_2024; on the materialized (native) BigQuery table typically estimates reading a large amount of data because there is no partition filter, so BigQuery must consider scanning across the entire table (all partitions, if any) to produce an exact row count; even though BigQuery can sometimes leverage internal metadata and columnar storage optimizations, COUNT() over the full dataset still requires enough reads to validate the total number of rows, which is why the estimated bytes processed are much higher than queries that restrict the scan using partition predicates (e.g., a date range) or that select fewer columns.	1
BigQuery scans all columns for COUNT(*) unless using metadata-optimized COUNT; estimated bytes processed equals table size.	1
[[I'm using Oracle OCI (Object Store + Autonomous Database)]] select count() from admin.EXT_YELLOW_TRIPDATA_PQ_mt mt; select FROM v$sql WHERE sql_text LIKE '%count()%admin.EXT_YELLOW_TRIPDATA_PQ_mt mt%'; Disk_reads = 4 x 8Kb = 32Kb The estimated bytes read is close to zero. This happens because the query is a simple COUNT() over a materialized table, and the database engine can retrieve the row count from metadata and statistics without scanning the actual data blocks.	1
SELECT COUNT(*) FROM `dtc-de-course-2026-486806.yellow.yellow_2024_non_partitioned`; This query will process 0 B when run. this is because BigQuery reads the data from metadata table and it simply reads the row count from metadata.	1
It estimates 0 bytes will be read. If the query touches no columns (e.g., COUNT(*)), BQ counts 0 columns scanned and reports 0 MB.	1
SELECT count(*) FROM `terraform-demo-485118.zoomcamp.yellow_tripdata_non_partitioned`	1
SELECT count() FROM `project_id.dataset_id.yellow_taxi_2024`; It is estimated to read 0 bytes data. For BigQuery Materialized Tables, the system automatically generates a row count in the metadata, which can be viewed under the Details tab. When we execute a SELECT count() without a WHERE clause, the BigQuery query optimizer recognizes that it doesn't need to scan the actual column data on the disk. Instead, it pulls the number directly from the table's metadata and returns it to us.	1
Answer: 0 MB (Read directly from table metadata.)	1
It estimate to read about 2.72 GB when run, mainly because it will come through all the record of the data as there are no partitioned or cluster provided for the query to filter on.	1
It processed 0 MB because count (*) on native data. BigQuery stores row count statistics and doesn't need to scan the actual data.	1
0 bytes. With external tables, BQ can't estimate beforehand the amount of data that will be read.	1
SELECT COUNT() FROM `dezoomcamp-486216.dezoomcampds.yellow_tripdata_non_partitioned`; Result: This query will process 0 B when run. This query will process 0 B when run. Reason: BigQuery stores metadata about tables, including the total row count. When we run SELECT COUNT() with NO WHERE clause, BigQuery doesn't need to scan any actual data - it just returns the metadata count.	1
SELECT COUNT(*) AS total_records FROM 'my_project.nyc_tlc.yellow_taxi_2024_materialized';	1
This query process 0 bytes of data. The reason is that BigQuery maintains metadata about a table such as the row counts, so it doesn't have to read that dataset to return the value.	1
According to the estimation 0 Bytes will be scanned as for count(*), in this case BigQuery does not have to do table scanning, this info can be fetched from the metadata itself.	1
There are 0 byte estimation for the query process because the query just simply refers to the table metadata.	1
SELECT COUNT() FROM yellow_tripdata_materialized; -- Estimated: 0 MB Answer: BigQuery uses table metadata (statistics) to return row count without scanning any data Metadata optimization: BigQuery stores row count in table metadata COUNT() retrieves this from metadata No actual data scanning needed Result: 0 bytes processed However, with WHERE clause: SELECT COUNT(*) FROM yellow_tripdata_materialized WHERE fare_amount > 0; -- Estimated: 77 MB (must scan fare_amount column) Must scan data to apply filter	1
0 Mo I suspect that since Bigquery is a columnar database, it has instantly access to this information without processing anydata?	1
Because BigQuery must read table data or metadata to compute the count. For a non-partitioned table, the estimate is typically the full size of the table like all columns in storage, because the engine needs to count rows. So you'll see a large byte estimate e.g. hundreds of MB or more, that's the cost of scanning the table to return the count.	1
~0 bytes, because when using count(*), the query uses metadata to compute the row count and does not need to scan any columns from the table	1
This query will process 0 B when run. Reason: Because BigQuery can get the answer through metadata. It doesn't have to scan real data.	1
SELECT COUNT() FROM `zoomcamp.yellow_tripdata_2024`; BigQuery estimates 0 bytes processed for this query. Although COUNT() computes a result over the entire table, BigQuery does not need to scan the underlying column data. Instead, it can retrieve the total number of rows directly from the table’s metadata.	1
BigQuery stores table metadata separately, including the total row count. Therefore, it needs no column access and gets the total count from the metadata itself.	1
0 bytes because it's reading the row count from the metadata	1
SELECT count() Estimated bytes and why: ================ Estimated bytes are very low or 0 MB This is so because BigQuery uses metadata for COUNT() on materialized tables and does not scan the actual data.	1
0 byte. And that's because BigQuery already knows the row count from the table's statistics so it doesn't necessarily have to read a single row of data to answer a count query	1
0 Bytes. BigQuery store table metadata internally. When I run thisSELECT COUNT(*) FROM `ny_taxi.yellow_taxi_materialized`, BQ reads it from metadata cache and does not scan any actual data.	1
0mb, because it gets the row count from the table metadata without scanning the data.	1
The estimated byte is 0. This is because the count is stored as part of the metadata and since there is no column selected. it fetches the count from the metadata.	1
SELECT COUNT(*) FROM zoomcamp.yellow_tripdata_parquet 0B, porque en las tablas materializadas, BigQuery ya mantiene el conteo de registros como parte de los metadatos de la tabla.	1
Currently it says the data estimate is 0mb. This is likely because BQ has cached the results of a recent identical full count to reduce repetitive overheads. Exploring the job history confirms this.	1
0 bytes , because bigquery had cached the data in temporary table after the first run	1
0MB (BigQuery stores metadata about row counts)	1
-- scanning 0 bytes select count(*) from `endless-office-485017-f8.dwh_taxi.yellow_tripdata_optimized` No execution is required because the number of row is already contained in the metadata table.	1
SELECT COUNT(*) FROM `datawarehouse-486704.rides_dataset.rides` How many bytes does it estimate will be read? 0 B Why? BigQuery will reuse cached results → 0 B.	1
0 bytes will be read because count(*) without a where clause can be answered directly from table metadata. Bigquery mantains row count information for each table: TABLE METADATA: =========== ... "row_count: 20332093" ...	1
0 bytes, even though writing count() is like asking the database to count all the data in the database, which should result in a very large cost, BigQuery has a metadata cache that stores information about the characteristics of the datasets in the database and the queries to access them, so when accessing queries with count(), BigQuery will only retrieve the data count from the metadata without scanning the data per column ('INFORMATION_SCHEMA. TABLE_STORAGE')	1
The answer is 2.72GB this because we are calling all colums which consume more resources.	1
Does NOT read data row by row Uses internal table metadata Knows how many rows there are without scanning columns 👉 Result: 0 bytes processed	1
BigQuery does not need to scan any column data to return the count of rows because: Metadata Storage: BigQuery maintains metadata about tables, including the total row count. This metadata is stored separately from the actual table data. COUNT() Optimization: When you execute COUNT() without any WHERE clause or other conditions, BigQuery can simply retrieve the row count directly from the table's metadata rather than scanning the actual data. No Column Access Required: Unlike COUNT(column_name) which needs to scan a specific column to count non-NULL values, COUNT(*) just counts all rows, which is a metadata property. Columnar Storage Benefit: Since BigQuery stores data in columns and maintains separate metadata, it can answer questions about row counts without touching any actual column data.	1
SELECT * FROM module3zoomcamp.nytaxi.external_green_tripdata_2019a ; 3768779	1
0 (Zero). Probably because it already knows how many records are there without having to query it.	1
0 bytes estimated. Because BigQuery stores table metadata including the total row count. When you execute SELECT COUNT(*), BigQuery doesn't need to scan any actual data.	1
0 byte BigQuery counts rows metadata cheaply	1
SELECT COUNT() FROM taxi_data.yellow_taxi_native; his query will process: 0 B BigQuery can answer COUNT() on a native table using table metadata, without scanning the actual data columns. BigQuery already stores: total row count table statistics storage metadata	1
0 MB it will read the data from the table metadata	1
In BigQuery, COUNT(*) doesn't read any data columns. Instead, it uses the table metadata (row count statistics) that BigQuery already stores.	1
This query will process 0 B when run. Because the database is retrieving the result from its metadata rather than scanning the actual data rows.	1
SELECT COUNT() FROM `dtc-de-course-485513.zoomcamp.yellow_taxi_materialized`; This query will process 0 B when run. COUNT() is a metadata-only operation. BigQuery stores table statistics (row count, size, etc.) and can answer this query without scanning any actual data. It simply reads the row count from metadata.	1
Its cached	1
It estimates that 0 bytes will be read. BQ references metadata instead of manually needing to count the rows like a true SQL language would.	1
0 bytes Both BigQuery and Athena resolve `COUNT(*)` from metadata (table stats / parquet footer row counts) without scanning data.	1
It estimates that 0B will be read because BigQuery is a columnar database and the SELECT count(*) query does not require reading any columns, it only needs to read the metadata of the table to get the count of the number of rows.	1
Result : This query will process 0 B when run. Reason: BigQuery stores metadata about tables, including the total row count. When we run SELECT COUNT(*) with NO WHERE clause, BigQuery doesn't need to scan any actual data - it just returns the metadata count	1
SELECT count() FROM your_materialized_table; BigQuery maintains metadata for its native materialized tables. For a simple count() without any filters, BigQuery doesn't need to scan the actual rows; it simply retrieves the pre-calculated row count from the table's metadata.	1
SELECT COUNT() FROM dlt-bigquery-484316.wk1_tf_dataset.2024_yellow_nyc_taxi_non_partitioned; bytes estimate for read: This query will process 0 B when run. REASON: For managed BigQuery tables, when you do an unfiltered COUNT(), BigQuery can return the row count from table metadata instead of reading the table’s storage.	1
SELECT COUNT(*) FROM public.yellow_tripdata_2024-01 Will be read 0B, Because BigQuery can uses the table's metadata to return the row count without scanning the actual data.	1
0. Because Bigquery don't need to read the table just see the metadata of it.	1
BigQuery must scan the entire table to compute COUNT(*), since there is no partition filter or column restriction. Therefore, the estimated bytes processed is approximately the size of the whole table.	1
0 MB. BigQuery maintains a highly optimized metadata store for every native (materialized) table. This metadata keeps a constant, real-time count of the total number of rows. COUNT(*) without filtering with a WHERE clause will allow BigQuery to simply read the pre-calculated row count from the table's metadata.	1
SELECT COUNT(*) FROM `de-zoomcamp-2026.taxi_data.yellow_taxi_trips`; Estimated bytes read: 0 bytes Since the query only asks for the total number of rows, BigQuery can answer it from table metadata instead of reading the data itself, resulting in 0 bytes processed.	1
0B COUNT() doesn't need to read any data columns. BigQuery stores table metadata that includes the total row count. When you run COUNT() without WHERE conditions, BigQuery simply reads the metadata instead of scanning the entire table.	1
It estimates that there will be 0B read from the table, because it's an external table, and BigQuery does not have access to the table storage statistics that would provide the size and row count that would normally be available in the internal dataset. https://docs.cloud.google.com/bigquery/docs/external-tables SELECT count (*) FROM `dezoomcamp-486221.de_zoomcamp.yellow_materialized_table`	1
sql SELECT COUNT() FROM `de_zoomcamp.yellow_taxi`; 0 bytes. For materialized BigQuery tables, `SELECT COUNT()` reads 0 bytes because BigQuery stores the row count in internal table metadata. It doesn't need to open or scan any column data since the result is already known. This is specific to native BigQuery tables because external tables since the data would live elsewhere (like GCS) and BigQuery would maintain metadata in a different way.	1
SELECT COUNT(*) FROM taxi_data.yellow_tripdata; It should be 0 MB because BigQuery stores table metadata separately, doesn't need to scan data.	1
The estimated bytes are zero because BigQuery uses metadata to answer global count queries. Since the total row count is already stored in the table's statistics, no data scanning is required unless a filter is applied.	1
It estimates it will take 0 bytes. This is because BigQuery stores the row count in the table's metadata. So when COUNT(*) is run, BigQuery simply reads the pre-calculated value from its metadata.	1
It processes 0B as the count of rows is stored in the metadata of teh table created so query engine does not have to access storage and send data over the network.	1
47.6 Because it is reading from the metadata table.	1
ZERO - WHY - Because BigQuery is Columnar database that keeps metadata about it - So it will explore that metadata for the required columns instead of the actual data and will return ZERO based on this.	1
The "Why?" BigQuery is smart enough to know that it doesn't need to read the physical data to answer this specific question. Metadata Storage: When you create a native table in BigQuery (like the materialized one you just built), BigQuery maintains real-time metadata about that table, including the total number of rows. Metadata vs. Storage Scan: When you run SELECT count(*), BigQuery simply looks up this number in the metadata header. It does not open a single column or read a single byte of data from the Capacitor storage. Result: The query finishes almost instantly, and the "Bytes Processed" remains 0 B. Note: If you ran this same query on your External Table (the one pointing to GCS), it would not be 0 Bytes. BigQuery would have to scan the Parquet files to count the rows because it doesn't manage the metadata for external files.	1
0B, the information for this is stored in meta data.	1
SELECT COUNT() FROM zoomcamp.yellow_tripdata_parquet The estimate number of bytes is 0 B and the reason is that with materialized tables, BigQuery already maintains the count of records as part of the table metadata. If we added a filter, we'd obtain an amout of bytes different than zero. For instance, the estimate of processed bytes for this other query is 155.12 MB. SELECT COUNT() FROM zoomcamp.yellow_tripdata_parquet WHERE VendorID = 2	1
0 bytes. BigQuery optimizes SELECT count(*) on materialized tables by reading the row count from cached metadata rather than scanning any column data. Since no specific columns are referenced, no data needs to be read from storage.	1
SELECT COUNT(*) FROM company;	1
0 bytes, cause Big Query stores metadata of the materialized table and has pre-calculate count of the total number of rows.	1
0 bytes bigquery knows this information based on the metadata	1
SELECT COUNT(*) on the materialized table scans the full table (all rows), so the estimate equals the full table size. The exact byte estimate depends on the table size shown in BigQuery for that dataset.	1
because when using SELECT COUNT(*) => dont mention about the column Bigquery use storage metadata instead of scanning column data	1
SELECT COUNT(*) FROM `applied-shade-485904-c9.zoomcamp_module_3.yellow_taxi_2024`; Estimate bytes is 0 B BQ uses table metadata to compute the query.	1
SELECT count(*) FROM dtc-de-course-485504.zoomcamp.yellow_tripdata_parquet; 0 Bytes read Bigquery assumes that this data can be fetched from the table's metadata or cached results	1
Query would be SELECT COUNT() FROM `data-warehouse-486723.nytaxi.yellow_tripdata_partioned_clustered` ytpc; And the estimated bytes are 0. When using COUNT(), BigQuery doesn't read the whole table, instead, it reaches to the metadata, which contains the information for total amount of rows	1
0bytes (we ran the query at the start of the homework and the results was cached	1
0B ,BigQuery uses metadata to get actual info.	1
2720000000 bytes Because I selected full table with '*' operator	1
SELECT COUNT(*) FROM `my-de-zoomcamp-2026.ny_taxi.yellow_taxi`;	1
BigQuery stores table metadata (like row count). For COUNT(*), BigQuery can answer the query without scanning the actual data, so no bytes are processed.	1
BigQuery keeps metadata about its tables, including the total number of rows. When you run a simple COUNT(*), it just reads that metadata instead of scanning the actual data, which is why the bytes processed show as 0	1
It estimates 0 MB (or very close to 0 MB). Because BigQuery uses metadata statistics for COUNT(*) when possible. It does not need to scan the full table because it already knows the row count from storage metadata.	1
This query will process 0 B when run. Because materialized tables have metadata with count of logic records.	1
0 Bytes. Why? BigQuery stores metadata (information about the data) for every table. This metadata keeps track of the total number of rows in the table. When you execute a SELECT count(*) query without any filters (WHERE clause), BigQuery simply reads this value from the metadata instead of scanning the actual data columns. Since no column data is read, the estimated bytes processed is 0.	1
SELECT COUNT(*) FROM `de-2026-hws.hw3.yellow_tripdata_2024`; -- This query will process 0 B when run. Explanation: This is because it is only referencing the metadata table, and not the colossus part.	1
`SELECT count(*)` estimate was 0 since BigQuery already has statistics of the table this can be seen in the details page of the table where it shows the number of rows.	1
SELECT COUNT(*) FROM `de-zoomcamp-2025-448114.yellow_tirps_data_hw.regular_yellow_tripdata_all` -> The answer is 0. It is a very efficient query, because it does not have to read contents of the rows; only count the number of rows.	1
0B. Since this query is counting how many rows are in the dataset, bigquery will simply read from the metadata that it has already stored about the data. It will also not query the data directly since no column has been specified in the query.	1
SELECT count() AS total_rows FROM dwh.yellow_2024_raw; In BigQuery, count can be answered using metadata (so the estimate may be 0 bytes or very small), because it doesn’t necessarily need to scan. I used Clickhouse, so there is a similar optimization (metadata read)	1
SELECT COUNT(*) FROM `composite-haiku-402317.nytaxi.yellow_tripdata_2024`; The estimated data size is 0 bytes. BigQuery caches data and reports 0 bytes from previously saved data at no cost.	1
- The estimated number of bytes processed is 0 because COUNT() can be answered using BigQuery's table metadata, without scanning any columns or table data. SELECT COUNT() FROM `de-zoomcamp-week3-486908.ny_trips_data_2024.yellow_taxi`	1
2.72 GB.	1
BigQuery stores the total row count in the table's metadata. It doesn't need to scan a single row to tell you how many there are.	1
SELECT COUNT(*) FROM zoomcamp.yellow_tripdata_2024;	1
BigQuery stores the total row count of native (materialized) tables as part of its table metadata. When executing a simple COUNT(*) query without any filters or conditions, BigQuery retrieves this value directly from the metadata, rather than scanning the underlying data columns. As a result, the query does not require reading any table data and therefore reports 0 bytes processed, making the operation extremely fast and cost-efficient.	1
0MB because no need to access data	1
0 bytes. because BigQuery uses table metadata to return the row count for COUNT(*) without scanning the whole table.	1
When you execute a `SELECT COUNT()` on a materialized (native) table, BigQuery does not need to scan the actual data blocks. Instead, it retrieves the row count directly from the table's metadata. BigQuery stores pre-computed statistics for every native table, including the total number of rows, which are updated whenever data is loaded or modified. Since no columns are actually read and no data is processed by the execution engine, the estimated and actual bytes processed will be 0*. This highlights the efficiency of BigQuery’s metadata management system compared to traditional databases or external tables, where a full scan might be required to determine the total record count.	1
SELECT count(*) FROM `YellowTaxiTrip.native_yellow_taxi`; This query will process 0 B when run. BigQuery retrieves the answer from metadata.	1
SELECT COUNT() FROM `ny_taxi.yellow_taxidata_2024`; Estimated Bytes to read: 0 bytes Because COUNT() doesn’t need to scan any data columns. BigQuery can satisfy this from table/partition metadata (row-count statistics) for a materialized or regular table.	1
SELECT COUNT(*) FROM kestra-sandbox-450522.de_zoomcamp.my_table; Will be read 0B. Because BigQuery can use metadata to return the row count without scanning the actual data.	1
SELECT COUNT(*) FROM `poetic-genius-486912-k5.ny_taxi.yellow_taxi_2024`;	1
Explanation: BigQuery retrieves the total row count directly from the table's metadata instead of scanning the data rows. Since no columns are read, the bytes processed estimate is zero.	1
0 bytes. Because it read from metadata.	1
SELECT COUNT() as total_records FROM `<GOOGLE_CLOUD_PROJECT>.nyc_taxi_data.yellow_tripdata_2024`; This query will process 0 B when run. If it detect COUNT(), it can automatically retrieve this information from stored metadata.	1
It estimates 0B. The reason for it as BigQuery won't need to scan the data for non-null values like in COUNT(VendorID) or anything else. It just presents the number of rows of the table which doesn't cost anything.	1
0 B run, because the data is from table metadata.	1
0 MB because of BigQuery's metadata optimization for COUNT() BigQuery does not need to scan the table data to answer COUNT(). Instead, it reads table metadata (row count stored internally) BigQuery already knows number of rows per partition and number of rows in table. So it can return result instantly without scanning columns. This works only when: COUNT() and no WHERE filter. Because BigQuery can use metadata. If you run this instead: SELECT COUNT(PULocationID) FROM table; Now BigQuery must scan a column to check NULLs. So bytes processed > 0. BigQuery can use table metadata to return total row count without scanning the underlying data, so COUNT() can be executed with zero bytes processed.	1
SELECT COUNT() FROM `solar-router-483810-s0.homework_3.yellow_taxi_native`; This query will process 0 B when run. This is because BigQuery can use metadata to compute COUNT() without scanning column data. Only works for COUNT(*), not COUNT(column_name)	1
Big Query's estimate is "0 B when run." My initial guess was that was likely because some of this information is already cached. When I looked at the execution-plan-graph, it was pretty clear that, due to the way Big Query works, record tallies of that kind are stored in readily-available locations like system catalogs or information-schemata, because something like Big Query is a "read-mostly" or "read-only" environment, and in such an environment, the total number of rows in a table is something that is statically known ahead of all queries.	1
Current query set to 0 byte usage, since the count is stored in the as part of the metadata so it is not selecting any columns.	1
SELECT COUNT() FROM `zoomcamp-ny-taxi-486822.zoomcamp_hw3.yellow_taxi_2024_bq`; This query will process 0 B when run. For managed BigQuery tables, BigQuery can sometimes compute COUNT() using internal table/partition metadata rather than scanning the actual data. That’s why it can estimate (and sometimes actually process) 0 bytes.	1
BigQuery (BQ) maintains metadata regarding the location and format of data within a bucket, which it uses to reference external data. However, the actual retrieval of that data is only triggered when a specific query condition is provided. Consequently, if data is only loaded into a bucket (as an External Table) rather than being stored within BQ, it is only natural that the estimated scan size for detailed queries - such as counting total rows - will appear as 0B prior to execution. This occurs because BQ does not pre-analyze the actual content of the external files. However, the moment you ingest that data into BQ's internal storage (Native Table), BQ goes beyond simply knowing the file location and format. It immediately records statistical information in its system catalog, including total row counts and the maximum and minimum values for each column. In this state, when you execute a SELECT count(*) query, BQ does not need to read a single bit of the actual data files; instead, it retrieves the results instantaneously by reading the row_count information stored in its metadata. This is precisely why, in professional practice, frequently accessed data is ingested directly into BigQuery’s internal storage rather than being left in a bucket - to ensure both cost reduction and performance optimization.	1
SELECT COUNT(*) FROM your_materialized_table;	1
The estimated read size is 0 B. The reason is that BigQuery stores table statistics, like the row count, in its metadata. Since I'm not filtering any data, the engine just looks up the count from the metadata rather than performing a full column scan.	1
SELECT COUNT() FROM datatalks-de-course-485418.zoomcamp.yellow_tripdata_regular; The estimate is 0 Bytes. Since the yellow_tripdata_regular was created from an external table, the regular table now lives in BigQuery. BQ now has access to the row and column metadata, so for simple COUNT() queries such as the one above, it can rely on this metadata alone without any processing.	1
BigQuery does not need to read the underlying data to answer a COUNT(*) on a materialized table (or any native table). Instead, it uses table metadata, which already stores: total number of rows total size column-level statistics Because the row count is stored in metadata, BigQuery can answer without scanning any data blocks at all.	1
SELECT COUNT() FROM `[proj_id].[dataset_id].yellow_tripdata_2024`; BigQuery shows 0 Byte processed because it does NOT need to scan table data to answer COUNT() on a materialized table, it uses table metadata instead. BigQuery only scans data when it needs column values, if metadata is enough, it scans nothing.	1
2.7 gb. As BigQuery is columar it need to read all the columnas in the able to it shows 2.7 gb	1
47.60 MB read all blocks on storage	1
0 bytes - BigQuery stores table metadata including row counts, so COUNT(*) doesn't require scanning actual data	1
```sql SELECT COUNT() FROM `[proj_id].[dataset_id].[materialized_table_name]`; ``` The answer: 0 byte BigQuery shows 0 B processed because it does NOT need to scan table data to answer COUNT() on a materialized table, it uses table metadata instead. BigQuery only scans data when it needs column values, if metadata is enough, it scans nothing.	1
It shows 0 because we are not selecting any particular column and BigQuery tables are columnwise stored	1
BigQuery stores the total row count of native tables in its Metadata. When you run a count with no filters, it just reads that single number from the metadata instead of scanning the actual data rows, resulting in 0 bytes processed.	1
Estimated bytes read 0 MB Why? BigQuery does not need to scan the table’s data to compute COUNT() on a materialized (native) table. Instead, BigQuery uses table metadata (row count statistics) that it maintains internally. Since no columns are read and no data blocks are scanned, the estimated bytes processed is 0 MB. This is one of the reasons materialized/native tables are more cost-efficient than external tables for aggregate queries like COUNT().	1
0 bytes, it is already store the meta data	1
0B. Selecting * doesn't require the query to look for a specific column or data set.	1
3.2GB. Because if will be reading all external data from yellow taxi	1
SELECT COUNT(*) as total_records FROM `your-project-id.de_zoomcamp_hw3.yellow_taxi_materialized`;	1
0 bytes Note: question is ambiguous. question should be clearly framed given there are a few tables created throughout the assignment. my answer is for the partitioned table. REASON: Because BigQuery stores table metadata that includes: Total row count Number of partitions Rows per partition When you run SELECT COUNT(*) on a partitioned or non-partitioned native table, BigQuery reads this metadata instead of scanning actual data. Result: 0 bytes processed, instant response. This works on: Partitioned tables, Non-partitioned tables Does not work on: External tables (no metadata, must scan files) The partitioning itself doesn't enable this - it's a feature of all native BigQuery tables.	1
The estimated bytes to read the data is around 0 MB. BigQuery uses internal(regular) table metadata, storage statistics and row count information maintained by the storage engine. Because of this, it can return the total row count without reading column data blocks.	1
0 bytes (uses metadata) -> BigQuery can answer SELECT COUNT() queries without scanning any data because: Metadata Storage: BigQuery stores table metadata including the total row count Column-Independent: COUNT() doesn't require reading any column values Query Optimization: The query engine recognizes this pattern and returns the metadata value directly Comparison: COUNT(*) → 0 bytes (uses metadata) COUNT(column_name) → scans column (needs to count non-NULL values) COUNT(DISTINCT column_name) → scans column (needs to identify unique values)	1
- BigQuery stores metadata about the table including the total number of rows. - When we use COUNT(*), BigQuery does not scan the materialized table but reads from the metadata. - This is why the estimated bytes processed is '0B'.	1
select count(*) from `decamp01.datacampbigquery03.yellow_taxi_optimized` 0 bytes because bigquery stores metadata	1
Big Query's estimate is "0 B when run.	1
BigQuery will process 0MB since the number of rows is stored in the metadata of the table	1
SELECT COUNT(*) FROM data-warehouse-486611.nytaxi.yellow_tripdata_non_partitioned; This query will process 0 B when run. Storage info: BigQuery store precomputed results for materialized view, BQ can return the result instantly from metadata.	1
SELECT count() FROM `sandbox-486719.rides_dataset.yellow_taxi_2024_native` ; Estimate: 0 bytes Why: BigQuery stores table statistics (like total row count) in its metadata. When a query like count() is run, BigQuery retrieves the pre-calculated number from the metadata layer instead of scanning the actual data blocks, making the query free and nearly instantaneous.	1
SELECT COUNT() FROM `taxi-rides-ny-485312.nytaxi.yellow_trip_data_managed`; 0B estimated. BQ just looks at metadata for count() which simply total rows in the table. Since it doesn't do any processing hence 0 B processed estimated.	1
The estimate number of bytes is 0 B, this is because BigQuery retrieves the count of entries directly from table metadata, and not from the actual data.	1
BigQuery stores table metadata, including the row count. When running SELECT COUNT(*), it retrieves this value directly from the metadata instead of scanning the actual data. Since the metadata is automatically kept up-to-date, the query processes 0 bytes.	1
SELECT COUNT(*) FROM yellow_taxi_2024;	1
0 bytes, because it can get the answer from table details (metadata) whitout having to read any data	1
0 MB Materialized views store precomputed results. BigQuery does not need to scan the underlying data to compute COUNT(*) because it already knows the total number of rows from the precomputation.	1
The query on the partitioning and clustering table estimates 0 bytes processed because BigQuery extracts the number of records from the Metadata without scanning data. The result is the same even if the query is executed on the non-partitioned and non-clustered table. However, if some filter is applied to the query, in this case BigQuery will perform a scan and there will be a difference in performance and costs if the table is partitioned/clustered or not.	1
0 bytes. because COUNT(*) uses table metadata so it doesn't need to scan the table	1
0 bytes BigQuery does not need to read the underlying data to answer a COUNT(*) on a materialized table (or any native table). Instead, it uses table metadata, which already stores: total number of rows, total size, column-level statistics. Because the row count is stored in metadata, BigQuery can answer without scanning any data blocks at all. That’s why the estimated bytes processed is 0	1
estimated: This query will process 0 B when run. BigQuery stores the total row count for native tables in its metadata. Since it doesn't have to scan any actual columns to find the total count of rows, the query is essentially "free" in terms of data processed.	1
The data is already cached in big query from a previous query result	1
This was my query: SELECT count() FROM `big-involution-291216.de_zoomcamp_hw3.yellow_tripdata_2024_non_partitioned`; It should be 0 B. Because BigQuery keeps metadata about tables, including the total row count. It doesn't need to scan the actual data rows to answer COUNT().	1
SELECT count(*) FROM `data-warehousing-486717.homework_3.yellow_tripdata`; --result: 0 B When a materialized table is created from an external table, BigQuery still tracks the source as an external table in its metadata. BigQuery’s query size estimator looks at the original source to estimate bytes scanned. External tables don’t have size metadata available in BigQuery, so it estimates 0 B.	1
It estimates 0 bytes. That's because when creating a materialized table, the information about the number of rows is computed and stored as metadata and BigQuery only has to resort on that,whenever we perform a "SELECT count(*)", instead of computing it again.	1
It estimates 0 bytes because BigQuery stores metadata about it's tables and the row count of the table is one of them, it can pull from the metadata rather than read the table.	1
Estimated 0B was used. It could be 0 because this query only use the metadata.	1
zero, all biquery had to do is just look up at the table metadata	1
select count(*) from `project-b60ec3fb-d46b-4909-ae8.mydataset.yellow_taxi_materialised`;	1
``` SELECT COUNT(*) FROM `project-37461d80-d5a2-4760-9d3.ny_taxi.yellow_tripdata_partitioned`; ``` BigQuery does not need to read the data to determine the number of rows; the number of rows is stored as metadata.	1
SELECT COUNT(*) FROM `project.dataset.materialized_yellow_taxi_2024`;	1
0 bytes. I don't know why.	1
It is estimated to process 0 bytes. BigQuery gets count(*) from table metadata and doesn't need to actually scan columns	1
Because BigQuery stores metadata for every materialized table. Running `SELECT count(*)` for a materialized table has BigQuery just look at the table's metadata.	1
SELECT COUNT (*) FROM ammar-zoomcamp.zoomcamp_hw3.yellow_tripdata_2024;	1
-- Creating External Table CREATE OR REPLACE EXTERNAL TABLE `trips_data_all.external_yellow_tripdata` OPTIONS ( format = 'PARQUET', uris = ['gs://taxi_data_2024/yellow_tripdata_2024-.parquet'] ); -- Creating Regular (Materialized) Table CREATE OR REPLACE TABLE `trips_data_all.yellow_tripdata_non_partitioned` AS SELECT FROM `trips_data_all.external_yellow_tripdata`; 0 bytes.	1
SELECT COUNT() FROM `noted-lead-448822-q9.taxi_data.internal_yellow_taxi_2024` Cette requête traitera 0 octets lors de son exécution. 1. Optimization of Materialized Tables: Materialized tables are designed to store pre-computed query results. This means that the data is already aggregated and optimized for fast queries, such as SELECT count(). BigQuery can use metadata to answer this query without reading the underlying data. 2. Statistics and Metadata: BigQuery uses statistics and metadata to optimize queries. For a count(*) query, it can simply use this information to return the number of rows without having to scan the entire table. 3. Read Cost: In the case of materialized tables, the read cost is often reduced because the data is already organized to minimize the volume of data that needs to be read to answer common queries.	1
It should reads all table data (or the smallest filled column) for gaining the number of rows. Because bigquery tables don't contain metadata about row count like parquet files.	1
0 Bytes. Because the information is fetched from meta-data of the table.	1
SELECT count(*) FROM `PROJECT_ID.nyc_yellow_taxi_2024.yellow_tripdata_non_partitioned`; Estimated Bytes: 0 B Why? BigQuery stores the total row count for materialized tables in its metadata. Since it can answer this specific query by just looking at the table's metadata without scanning any actual data rows, the estimated bytes read is 0.	1
0B, because BigQuery saves ths in table details on creation.	1
Usually 0 MB because BigQuery uses metadata/table statistics to answer count(*) without scanning data in many cases, especially for non-partitioned tables with up-to-date stats	1
0 bytes (metadata)	1
SELECT DISTINCT COUNT(*) FROM `de-camp-01.de_hw_03_dataset.yellow_tripdata_nonpartitioned`; For some reason (caching maybe?), all my byte estimations were zero. I tried to reset the caches, but it didn't work.	1
This query will process 2.72 GB when run SELECT * FROM `project-709917fd-48b8-4e7f-9c6.taxi_data.yellow_taxi_materialized`;	1
o B when run, because it gets the data from table metadata	1
It says it'll run 0 because it's looking at the metadata instead of going through the actual data	1
0B because BigQuery uses internal metadata for row counts instead of scanning the actual data.	1
BigQuery estimates that 0 bytes will be read, because BigQuery can retrieve the number of rows from the table metadata without scanning the actual data. The total rows for each table are stored within INFORMATION_SCHEMA.TABLE_STORAGE.	1
BigQuery automatically records the information 'how many rows is there in this table' in a separate 'metadata store' every time data comes into a table, so there is no need to scan the data. As a result, the estimate is 0 bytes.	1
The query will read 0 bytes because a SELECT count(*) on a materialized view or table typically only needs to access metadata or an internal count stored by the database system, rather than scanning the actual underlying data rows. The database engine optimizes this operation to avoid a full table scan.	1
select count(*) from `nytaxi.mat_yellow_tripdata`; Now it estimates 0 bytes. That is because I ran it before and the data has been stored in cache.	1
0 bytes, since this is actually retrieved from the metadata of the table	1
SELECT COUNT(*) FROM starlit-effect-484216-a1.zoomcamp202625.materialized_yellow_tripdata_partitioned_clustered; BigQuery estimates that the query above will process 0B when ran. The reason behind this is that the number of rows in a table is already stored as metadata and without any filtering conditions BigQuery can just access that value from the metadata.	1
0 bytes (or very small) BigQuery uses table metadata for COUNT(*), so it doesn’t need to scan the actual data.	1
SELECT COUNT() FROM `kestra-taxi-pipeline.homework2026.materialized_yellow_2024`; Answer : 0 BigQuery stores table metadata for native/materialized tables, including the total row count. For simple aggregations like COUNT(), BigQuery can answer the query using only metadata without scanning any actual data.	1
SELECT DISTINCT PULocationID FROM `nimble-courier-485614-g9.ny_taxi_dataset.external_yellow_tripdata_2024`; 0 it's on metadata for the row counts	1
Preview: This query will process 0 B when run. Explanation: BigQuery stores the total number of rows in the table's metadata. When you run a SELECT count(*) without any filters, BigQuery retrieves this value directly from the metadata instead of scanning the actual data rows, resulting in 0 bytes processed.	1
it estimates 0 bytes. This might be caused by caching. Another explanation would be that the query optimization would have converted the query to read the table metadata to get the rows count instead of triggering a full table scan.	1
SELECT COUNT(*) FROM your_materialized_table;	1
Estimated bytes: 0 bytes. BigQuery stores table metadata (including row counts) internally, so a COUNT(*) without any filter does not need to scan any actual data because it reads the count directly from metadata.	1
It estimates 0 B because it can answer this query using only the table metadata without scanning any actual data.	1
0KB. The estimated bytes processed is zero because BigQuery can answer this query using metadata only. For native (materialized) BigQuery tables, BigQuery stores the row count as table metadata.	1
0 B, because it is metadata-only operation	1
SELECT COUNT(*) FROM `kestra-sandbox-486514.nytaxi.yellow_tripdata_partitioned`; for me it showed - This query will process 0 B when run. I really don't know the reason. Its because the total number of rows in already present in table description which implies that it must be present in meta data.	1
SELECT COUNT() FROM `de-zoomcamp-2026-486900.trip_data.yellow_trip_mat`; It estimates 0 bytes. It estimates 0 bytes. BigQuery is smart 😊 - COUNT() does not read columns - It only needs metadata - No actual data scanning is required - For materialized (native) tables - BigQuery stores row counts in metadata - So, no column scan needed ➡️ Result: Estimated bytes processed = 0 bytes for materialized table.	1
SELECT COUNT(*) FROM `de-zoomcamp-hw3-486709.yellow_taxi.materialized_yellow_taxi`;	1
155.12 MB will be read, because it's have to do a full scan	1
SELECT COUNT() FROM `project.dataset.materialized_yellow_taxi_2024`; It estimates that 0 bytes will be read because COUNT() does not require scanning any actual columns. Native BigQuery tables can use table metadata to return the row count and since no column data is read, no data is scanned, so the estimated bytes processed is 0 MB.	1
0 bytes. BigQuery estimates 0 bytes because the row count is already stored in the table's metadata. It does not have to scan the table as it can retrieve it from table's internal metadata/statistics.	1
0, Because it stored at the metadata	1
SELECT COUNT(*) FROM zoomcamp.yellow_2024;	1
zero bytes, bigquery optimizes data fetch by not needing to scan data when using COUNT(*))	1
"This query will process 0 B when run." As the query neither reads any particular column, neither has filtering and ordering, such row counting will be done based on the table metadata. The metadata stores "rows_count", "size_bytes" and other informational fields.	1
When you run a SELECT count(*) on a native materialized table in BigQuery, the estimated bytes read will be: 0 B (Zero Bytes). Instead of scanning the actual columns or rows (which would cost money), the query engine simply pulls the row_count value directly from the table’s metadata.	1
SELECT COUNT(*) FROM zoomcamp.yellow_2024	1
``` -- SELECT count() query FROM the materialized table you created SELECT COUNT() FROM `project.dataset.regular_yellow_taxi_2024`; ``` * ANSWER: * Estimated bytes processed = 0 B * REASON: * because BigQuery being a warehouse, already has metadata of the number of records in the materialized / regular table. * so no minimal to no processing is needed to display the metadata cached: number of records in the table as the result of this query * thus the estimated bytes processed shows as 0 bytes	1
SELECT COUNT(*) FROM `kestra_dwh.nyc_taxi_datasaet.yellow_tripdata_materialized`;	1
0B, because the query can be answered entirely from the metadata of the materialized table.	1
select count(*) from gothic-sled-453213-i2.nytaxi.yellow_tripdata; it estimate 0 byte because it has cahced the result	1
A SELECT count(*) query on a native table estimates 0 bytes because BigQuery retrieves the row count directly from the table's metadata rather than scanning the actual data files.	1
It estimates it will read 0 bytes.Because it doesn't read the columns, just counts them.therefore not needing to go threw the file it does process anything	1
SELECT count(*) FROM yellow_taxis_sg.yellow_tripdata_non_partitioned; 0	1
-- Count all lines SELECT COUNT(*) as total_records FROM `de-course-485418.taxi_data.yellow_tripdata_2024_non_partitioned`; It is already loaded, so it takes 0 B. No new columns created, so nothing new to store yet.	1
0 because COUNT(*) just looks at the table info to see how many rows there are, It doesn’t need to read all the data. External tables have to read the parquet files, so they use more data.	1
Zero bytes estimated to be read. BigQuery does not always scan the table when running 'COUNT(*). Instead, it stores raw metadata.	1
0 bytes are estimated because BigQuery can answer COUNT(*) using table metadata (row counts stored in storage statistics) without scanning any data for materialized table.	1
0B I think it's a pre-calculated value stored in memory to avoid scanning the entire table	1
``` SELECT COUNT(*) FROM `de-zoomcamp-487008.de_zoomcamp.yellow_tripdata_non_partitioned` ``` This query will process 0 B when run. BigQuery do not read any data because the total number of rows is stored in the table's metadata.	1
estimated 0 MB because BigQuery uses table metadata for count(*) and does not scan actual column data.	1
select count() from demo_dataset.yellow_tripdata_non_partitioned; -- This query will process 0 B when run. select count() from demo_dataset.yellow_tripdata_partitioned_clustered; -- This query will process 0 B when run. The reason is: COUNT(*) reads table metadata to get the count, so it doesn't cost anything, it works for non-partitioned as well as partitioned tables. https://stackoverflow.com/questions/11282798/how-does-bigquery-query-analysis-pricing-work	1
Currently it shows me 0 B, because I've executed it before hence the result have been cached.	1
0 Bytes It’s essentially a free query!	1
BigQuery: "This query will process 0 B when run." There were no bytes processed since `COUNT(*)` gives you the overall number of rows, which is already stored in the metadata of the table, which is used instead of processing the entire table.	1
SELECT COUNT() FROM `dezoomcamp.yellow_tripdata_non_partitioned` This query will process 0 B when run Because BigQuery already knows the row count. For native (materialized) BigQuery tables, BigQuery maintains table metadata that includes: - total number of rows - column statistics - storage layout info COUNT() does not need to read any column data at all. So instead of scanning rows, BigQuery: - reads the metadata - returns the precomputed row count	1
0B will be read. This is because BigQuery keeps the table count in metadata where it will read it from when that query is run. So it won't do any table scans for this specific query.	1
SELECT count() from `kestra-dataengg.zoomcamp.yellow_tripdata_2024_nonpartitioned`; This query will process 0 B when run, because BigQuery can answer count() from table metadata (i.e., number of rows stored) without scanning the full columnar data blocks of the materialized table.	1
Estimated bytes to read are 0B, because the data is not present in Big Query but in GCS. select count(*) from datazoomcamp-484706.nyc_yellow_taxi_data_hw_nits.yellow_taxi_trips ;	1
Bytes processed: 0 B (results cached) This happens because the same SELECT COUNT(*) query was executed before and BigQuery reused the cached query result. Since the underlying materialized table did not change, BigQuery did not need to scan the table again and simply returned the cached result, resulting in 0 bytes processed.	1
SELECT count() FROM `terraform-runner-485512.ny_taxi.yellow_tripdata_2024_non_partitioned`; The estimated bytes for SELECT count() is 0 MB because BigQuery retrieves this information from the table's metadata rather than scanning the actual data files.	1
It will read 2.72GB a Materialized Table often stores data in a way that requires scanning to ensure the result is fresh. If you are using count(*) on a complex Materialized Table (especially one with joins or filters), BigQuery may decide it needs to read the smallest column to verify the count	1
0 B estimated. Because it already stores this as metadata.	1
SELECT COUNT() FROM `dezoomcamp_hw3.yellow_taxi_2024`; Estimated bytes: 0 B (or near-zero metadata read). Reason: BigQuery can answer COUNT() from table metadata, so it does not need to scan all data blocks.	1
SELECT count() from `curious-helix-484819-a6.taxi_dataset.yellow_taxi_trips`; SELECT COUNT() often shows 0 MB processed because BigQuery can answer it using table metadata, without scanning the actual data.	1
The estimated number of processed bytes is 0 B because, for materialized tables, BigQuery stores the record count in the table metadata. As a result, no data needs to be scanned to answer the query. If a filter were applied, the estimated bytes processed would be greater than zero. For example, another query shows an estimated 155.12 MB of processed data.	1
When you run `SELECT count(*)` query, BigQuery returns 0 bytes processed. This is because BigQuery stores the row count in table metadata, so it doesn't need to scan the actual data rows to give us the answer.	1
It estimates 0 B for counting the rows in the materialized table because once the regular table is created and BigQuery has processed it, it stores table metadata which includes total rows, min/max, null counts and column statistics. Therefore, when SELECT COUNT(*) is performed it checks the metadata and does not scan the table for results.	1
BigQuery keeps information about native tables. It already knows the total number of rows from its own internal statistics.	1
It estimates 0 B when run. Because of how materialized views store metadata. As this query does not include any WHERE clauses, the total row count can be obtained directly from the metadata.	1
SELECT COUNT(*) FROM zoomcamp.yellow_tripdata_parquet	1
0 because that is the default count for materialized/native tables.	1
It will take 0 B because bigquery uses metadata to answer simple COUNT() queries without filters. bigquery only scans the table when we run count() with filters.	1
SELECT COUNT(*) FROM `cohesive-folio-485508-e4.zoomcamp.materialized_yellow_tripdata` ; -- Bigquery calcule le coup seulement quand les colones sont explicitement només -- et cette information est présente dans les metas datas	1
It shows 0 Bytes estimated. This is because big query stores metadata such as row count, and in the case of this query it can use that to answer total number of rows without needing to read the table.	1
COUNT(*) requires scanning the entire materialized table. Since partition pruning cannot be applied, BigQuery must read a large amount of data, resulting in high estimated bytes processed.	1
SELECT COUNT(*) FROM zoomcamp.yellow_tripdata_parquet 155.12 MB	1
SELECT COUNT(*) FROM de-zoomcamp2026-486215.zoom26_module3_yellowtaxi.yellow_tripdata_nonpartitioned Estimated bytes read: 0 B The number of rows of the materialized table has already been stored in the metadata of the table, therefore no column scanning is required.	1
0KB. It fetches the info from the metadata.	1
OB because BigQuery get its answers from the table Metadata, we can see the number of rows under the Storage Info section in the Details views of the table. Note that this work only for internal tables.	1
SELECT COUNT() AS total_records FROM yellow_taxi_materialized; Estimated bytes read: ~155 MB (approximately 155.12 MB). Even though the query only uses COUNT(), BigQuery must scan all rows of the materialized table to compute the result. Since the query has no filters or partitions, a full table scan is required. Due to BigQuery’s columnar storage and compression, only a small amount of data per row is read, resulting in an estimated scan of around 155 MB instead of several gigabytes.	1
0MB Because bigquery will use metadata when it execute count(*).	1
0 bytes, because Bigquery pulls table metadata instead of scanning the whole table.	1
Its because - COUNT(*) requires reading all row groups - There’s no filter - BigQuery must scan the full dataset	1

Calculated: 13 February 2026, 20:59