Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit c1504c8

Browse files
more quick fixes
1 parent 2a2f02c commit c1504c8

File tree

1 file changed

+2
-2
lines changed

1 file changed

+2
-2
lines changed

‎_posts/2024-08-05-temporal-table-weirdness.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -178,7 +178,7 @@ END;
178178
GO
179179
```
180180

181-
The basic idea here is...Grab the rowcount above and below a specific point in time. Since the table is insert only, this will tell us exactly how many records are inserted, vs cleaned up by the retention policy cleanup job.
181+
The basic idea here is...Grab the rowcount above and below a specific point in time. Since the table is insert only, this will tell us exactly how many rows are inserted, vs cleaned up by the retention policy cleanup job.
182182

183183
I ran the above proc every 5 minutes for a few days and then I ran this analysis query to see what it looked like:
184184

@@ -261,4 +261,4 @@ I thought it would be cool if I could inspect the actual contents of the columns
261261

262262
Well...after about 5 hours of pulling my hair out...I discovered that `sys.column_store_segments` contains a `min_data_id` and a `max_data_id` value, but for columns of type `datetime2` it's just the raw value, rather than a pointer to some dictionary value or something...
263263

264-
So my next blog post will likely be how I figured that out and my solution for it. I didn't want this post to be even longer than it already is 😂
264+
So my next blog post will be about how I figured that out and my solution for it. I didn't want this post to be even longer than it already is 😂

0 commit comments

Comments
(0)

AltStyle によって変換されたページ (->オリジナル) /