PHPMem v2.0.1

Version
1.6.45
Uptime
15 days 20 hours 21 minutes 56 seconds

Memory

Total
512MB
Used
9,38MB (1.83%)
Free
502,62MB

Keys

Current
11 436
Total (since start)
35 066
Evictions
0
Reclaimed
738
Expired Unfetched
0
Evicted Unfetched
0

Connections

Current
6 / 1 024 max
Total
179 667
Rejected
0
llm:5ef072729188e27bef9fded35ea1ce9f5aa6f938284ac07897e382ed50851d02
TTL 6 days 7 hours 50 minutes 30 seconds Size 2,54KB Export
Edit
# Time dimension: what I could and couldn't establish **Short answer:** The dataset does have a time dimension, but my investigation never queried the data. I can't point to specific spikes, dips, or breaks. Only the table structure is confirmed. ## What the evidence supports - The source table is `semi_conductor_se`. It holds stock-style price and volume data: `open`, `high`, `low`, `close`, `volume`, by `company_name` and `date`. - The gold tables cover the time dimension at four grains: year, year-month, day, and day-hour. - `semi_conductor_se_by_date__yyyy`: **14 rows**, so about 14 calendar years. - `semi_conductor_se_by_date__yyyy_mm`: **164 rows**, about 13.7 years of months. - `semi_conductor_se_by_date__yyyy_mm_dd`: **3,537 distinct dates**. - There are **152 companies**. - The company-by-year table has **1,785 rows** and the company-by-month table has **20,499 rows**. Both are far below what a full panel would give (152 × 14 = 2,128 company-years and 152 × 164 = 24,928 company-months). So **not every company is present in every period**. Companies probably enter and leave the data, which would be a structural break in coverage. - The day-hour tables have the same row counts as the daily ones (3,537 and 422,729), so the data is daily. The hour grain adds no information. - The company-by-day table has **422,729 rows** over 3,537 dates, an average of about 120 companies per date (my calculation from those two figures). That also suggests uneven coverage over time. ## What remains unknown I did not obtain any of the following, so I make no claims about them: - Which years or months had volume spikes or price dips. - Whether known market events (for example 2020 or 2022) appear in the data. - Where the gaps in the 3,537 trading dates fall. About 14 years would normally give roughly 3,500 trading days, so the count looks plausible, but I didn't check for gaps. - When company coverage changes (`row_count` by date or month). ## Suggested next queries 1. `semi_conductor_se_by_date__yyyy_mm`: check `volume__sum`, `close__avg` and `row_count` by month. Look for large month-over-month changes. 2. `semi_conductor_se_by_date__yyyy_mm_dd`: rank days by `volume__sum` and by the change in `close__avg`, and check the date sequence for gaps. 3. Check `row_count` by date or year to see when the number of companies changes. Do this before reading any price or volume trend, because a change in coverage can look like a spike or dip.