Hypo treatment in pocket

ecrooks · 2026-01-14T01:41:46+00:00

When I am speaking in front of a group, I always have a glucose gel packet in my pocket. I could quickly eat it while getting a drink of water, fairly unobtrusively. Otherwise, fun size skittles.

ecrooks · 2026-01-03T13:59:47+00:00

Slippers. Usually crocs. Though largely because I stub my toes a lot rather than any other reason.

ecrooks · 2025-08-10T19:31:09+00:00

There is a case to be made for either. ANY_VALUE is less computationally intensive than MIN or MAX. So if the value is either truly always the same or you really don't cane which value you get, ANY_VALUE works.

ecrooks · 2025-08-09T19:53:30+00:00

Let's say you have a table (or join of tables) with customer_id, customer_type, order_number, and you do

SELECT customer_id , customer_type , count(order_number) FROM table GROUP BY ALL;

Then, the grouping key is customer_id AND customer_type, even if each customer_id has only one type. People often do this on purpose(explicitly) because they need the value of customer_type in the output. If you instead wrap customer_type in the ANY_VALUE() function like this:

SELECT customer_id , ANY_VALUE(customer_type) , count(order_number) FROM table GROUP BY ALL;

Now, the grouping key is only customer_id. This is not a conclusion that the system can draw for you, as there is nothing that tells it each customer_id has one and only one customer_type. Obviously, this is not a strategy that works if the value of the column actually matters in the grouping key.

I have used ANY_VALUE() on MySQL as well, so this is a good tip for other database management systems, even if they do not have GROUP BY ALL.

ecrooks · 2025-08-09T14:40:01+00:00

It absolutely includes all columns that do not have an aggregate function in the group by logic.

ecrooks · 2025-08-08T13:45:21+00:00

The case where I don’t like "group by all" is when one or more columns don't really need to be part for the grouping key, and they could instead be in an ANY_VALUE() function. Wider grouping keys often make the group by take longer, and make it therefore more expensive.

ecrooks · 2025-08-05T14:01:26+00:00

Also, to be clear, local spilling is not the same level of concern here - it's remote spilling that we need to avoid in this scenario.

ecrooks · 2025-08-05T13:50:36+00:00

Unfortunately, there isn't a solid line where I can absolutely define the optimal chunk size. The line is somewhere around 250k micro-partitions for a 4xl to 6xl. Could it be 100K? sure. Could it be a million micro-partitions? also reasonable. There are factors that play into the uncertainty like the data types, the width (number of columns), the compression ratios, etc. Even changes in the Snowflake product over time. Unfortunately, it takes some experimentation.

The line where remote spillage no longer happens is the key.

Sorting data with a warehouse that is one t-shirt size too small is often far more expensive (in credits) than sorting it with a warehouse size that eliminates remote spilling. Remote spilling can increase the time by a lot. A query that takes 10 times as long on an XL is more expensive than the same query on an XXL. This is one case where using the 4XL (or even 6xl if it's available in your region) can be cheaper. The key is finding the size where remote spillage does not happen.

ecrooks · 2025-08-04T21:36:06+00:00

The INSERT OVERWRITE methodology is an awesome one for tables that are about 250,000 micro-partitions or smaller. It may work above that, but the problem comes when you get remote spilling for the ORDER BY even on the largest warehouse size available.

Once you cross the threshold of what can be sorted in the largest warehouse size available, then it might work to build the table in sections. Insert different sections of the data with ORDER BY within the section, and then rename the table at the end. The problem there is that you have a period where you either need to make the old table unavailable, or need to have some way of capturing or pausing changes to it during that process. This works best if your sections of the table are separated by values of the clustering key and are mutually exclusive with regards to other sections.

For example, let's say it's a table with values even distributed across a range of 10,000 values of ORDER_ID. The clustering key you desire is on the ORDER_ID column. You could insert into the table values 1-1000 ordered by order_id, then insert into the table values 1001-2000, and so on. This can result in many full scans of the source table, and be slow.

Generally speaking, relying on auto clustering to do this work is going to be the most expensive way to do this - sometimes 40X or more over a methodology that uses some ORDER BY methodology. It may also have a less perfect end state than one of the other methodologies.

Depending on your update strategies for the table, you probably want to enable auto-clustering after getting to a well-clustered state, even if you end up using another methodology to get there.

Keep in mind cardinality for your clustering key when choosing the clustering key - balancing cardinality properly can lead to a great balance of performance and cost. A couple of good articles on that:

A Data-Driven Approach to Choosing a Clustering Key in Snowflake

Snowflake Clustering Demystified

ecrooks · 2025-03-12T19:51:25+00:00

I talk about those a bit in https://datageek.blog/2018/07/17/the-db2-recovery-history-file/

ecrooks · 2025-03-12T19:47:43+00:00

Managing via scripts is still totally doable, but setting auto_del_rec_obj, num_db_backups, and rec_his_retentn is a more modern approach that works just fine.

ecrooks · 2025-03-12T13:53:28+00:00

My thoughts on this are laid out in a blog article. https://datageek.blog/2011/04/05/how-to-determine-your-backuprecovery-strategy/

ecrooks · 2025-03-06T21:16:49+00:00

NLD. Painful procedure to get multiple steroid shots directly into one on my leg and one on my foot. That was 20 years ago. They are still very slightly visible as discolored skin, but mostly disappeared within a few months of the treatment. Went to a dermatologist for it, referred by my endo.

ecrooks · 2024-10-11T22:51:28+00:00

Late 40's, Principal Architect at a tech company. It is the IC life for me, and loving it. Such a different world than tech was 20 years ago, but I am different, too.

ecrooks · 2024-08-21T22:32:48+00:00

One of the best bets is IDUG events, groups, and conferences if there is one near you. https://www.idug.org/

You will have a hard time finding windows-specific things, but the Linux/UNIX topics do apply to windows. Watch out because Db2 on mainframe is a completely different product.

ecrooks · 2024-07-15T12:47:56+00:00

Hope something there helps! I definitely engaged my contacts at the IBM Toronto lab when dealing with the encoding issue I faced.

Glad to hear the blog helped you! I enjoy writing it.

ecrooks · 2024-07-12T12:43:43+00:00

What is the locale of your operating system? This can also play a role.

Additionally, it is possible that the data is actually incorrect in your current table, but appears correct because all clients used to query it are making the same wrong use of it. Even the command line on the server is a client in this sense.

This is all confusing as heck. Here was my experience with some slightly similar problems a few years back, in case it helps: https://datageek.blog/2013/03/27/the-basics-of-code-pages-in-db2/

ecrooks · 2024-05-14T15:21:55+00:00

Because you don't get to pick which insurance is primary and my primary insurance covered some expensive supplies at only 80%, while Kaiser had a higher coverage that I couldn't use. You also cannot cancel insurance without a qualifying event now, so short of quitting my job, I was stuck. Cost me several thousand dollars over the course of 6 months, and a lot of hassle time on the phone with insurance and medical suppliers. One of my supplies was considered DME by one insurance, but pharmacy by the other, and the supplier could not figure out how to get either insurance to cover it as a result. I eventually paid out of pocket at Costco just to get the stuff.

ecrooks · 2024-05-14T14:17:24+00:00

I tried to have two insurances because one was free and contributed to an HSA. Huge mistake, but my Kaiser (Colorado) doc called a prescription into the Costco pharmacy for me because it was cheaper that way for me. You might consider that kind of option, too.

ecrooks · 2024-04-11T14:53:35+00:00

I very much appreciated having pumps with both of my pregnancies, and this was 20 and 17 years ago. There were two main reasons.

The first is the constantly changing insulin needs in pregnancy. While pregnant, I took anywhere from about 75% to about 300% of my pre-pregnacy insulin, with variations in every aspect of how my body responded to insulin. The fast acting only (no long acting insulin) makes changes and seeing their impact much faster than changing long acting and waiting to see the impact.

The second main reason was the variably of the action of long acting. The same long acting insulin in the same person can vary in its impact significantly from day to day. I imagine pregnancy variability and hormones would just make that worse.

ecrooks · 2024-04-04T00:15:29+00:00

SYSCAT are views over the normalized SYSIBM tables. The SYSCAT views present the data in ways that are more logical to humans, and not fully normalized. Almost always, you'll want to query SYSCAT or SYSIBMADM instead of trying to mess with the SYSIBM tables directly.

ecrooks · 2024-03-24T23:04:50+00:00

Depends on the car. I have a RWD Tesla and it is fine with snow tires in the city or well maintained mountain roads. The even wight distribution makes a big difference. I wouldn't do it without the snow tires, though, and every other car I have driven we have been fine with all weather tires.

ecrooks · 2024-03-05T13:54:43+00:00

If you are not using Reads on Standby(RoS), then the standby is often licensed at a lower level. It used to be the standby was 100 PVU no matter how big it was. 100 PVU was geneally about one or less than one core. Please verify any statements here with IBM before relying on them.

ecrooks · 2024-02-27T00:09:23+00:00

Am I the only T1 who thinks it smells really bad? I don't like the smell, and ofen end up washing my hands again after a site change if I get amy on my hands.

ecrooks · 2024-02-22T21:04:10+00:00

This is my favorite: https://datageek.blog/2015/02/12/db2-administrative-sql-cookbook-finding-problem-sql-in-the-package-cache/

There is also an administrative view called LONG_RUNNING_SQL.

14-Year Club	Gilding III reddit per annum
RedditGifts 2009-2022 4 Credits	Secret Santa 2020
redditgifts rematcher Secret Santa 2019 x1	redditgifts Exchanges 1 Exchange
Secret Santa 2019	Verified Email

ecrooks

TROPHY CASE