PHPMem v2.0.1
Version
1.6.45
Uptime
17 days 12 hours 13 minutes 12 seconds
Memory
Total
512MB
Used
12,72MB (2.48%)
Free
499,28MB
Keys
Current
14 060
Total (since start)
40 994
Evictions
0
Reclaimed
760
Expired Unfetched
0
Evicted Unfetched
0
Connections
Current
14 / 1 024 max
Total
238 581
Rejected
0
llm:b61d21da163e7c0f834a93733f4b291742c9f53b5dbfaa9a7c4c5a8872348bf1
Edit
**Size**
- **Rows:** 718,470 across 5 tables, which matches the dataset card and the row counts I queried.
- `raw_kaggle`: 237,205
- `return_kaggle`: 237,196
- `serve_kaggle`: 237,185
- `players_tournament_man_`: 6,422
- `players_man_`: 462
- **Columns:** the dataset card lists 78 columns in total: 21 each in the three match tables, 8 in `players_tournament_man_` and 7 in `players_man_`.
- The metadata overview I queried reports fewer: 17, 17, 17, 4 and 3, which sums to 58.
- I did not resolve this mismatch. I'd trust the card's 78, since it gives the full per-table breakdown, but the metadata count may reflect a different way of counting columns.
**Time period**
- **Match tables:** `Date` is stored as text. Once parsed, all 237,205 `raw_kaggle` rows, 237,196 `return_kaggle` rows and 237,185 `serve_kaggle` rows converted cleanly. All three tables span **13 Aug 2001 to 28 Oct 2024**, so the data covers roughly 23 years.
- **Earlier ranges were misleading:** ranges like "1-Apr-2013 to 9-Sep-2024" on the card come from sorting the date text alphabetically, not chronologically. Don't rely on them.
- **Players-by-tournament table:** `players_tournament_man_.year` runs from 2002 to 2024 with no nulls.
- **Player summary table:** `players_man_.playing_years` is a text list of years (for example 2002 through 2024), not a proper date column.
The dataset therefore covers about 718 thousand rows of men's tennis data from 2001 to 2024. The match-level tables hold one row per player per match, and the two player tables are smaller summaries.