Press "Enter" to skip to content

Curated SQL Posts

Conceptualizing the Agent2Agent Protocol

Published 2026-08-05 by Kevin Feasel

Paul Brebner continues a series on Apache Kafka and the Agent2Agent Protocol. Part 3 explains the details of the protocol:

In Part 2, we discovered that A2A’s object model centres on the “nouns” Agent Card, Task, Message, Part, and Artifact. A client sends messages; the remote agent responds with an immediate Message or a stateful Task. Artifacts — the durable outputs — live on the Task, not as a separate top-level response type.

This post covers the “verbs”: how agents find each other, how work flows at runtime, and the confusions that surfaced when I first read the specification (but are hopefully clarified by the end of this blog). These runtime patterns allow agents to discover each other, delegate work, track long-running operations, and exchange results across distributed systems. (Note: Part 4 will add sequence and state diagrams plus concrete request/response traces.)

By the end of this post, you’ll understand the core runtime flow behind the A2A protocol and how it supports scalable agent communication architectures that can be combined with technologies such as Apache Kafka.

Part 4 visualizes the different components:

In Parts 1-3, we treated the topic in prose: why multi-agent interoperability matters (Part 1), the core A2A objects (Part 2), and the operational patterns in (Part 3). Useful, but when I turned to implementation, I kept wanting sketches on the table: where modules sit, how objects connect, what the wire sequence looks like, which task states are legal.

The diagrams that follow are that layer. They provide a visual guide to the Agent2Agent protocol and help translate the specification into something easier to design, implement, test, and reason about.

Leave a Comment

A Comparison of R GUIs

Published 2026-08-05 by Kevin Feasel

Bob Muenchen puts together a comparison:

Graphical user interfaces for the R language are easy to use and getting more powerful all the time. Here is my updated comparison of jamovi, JASP, BlueSky Statistics (free & Pro), Rattle, RKWard, R-Instat, R AnalyticFlow, and R Commander.

With so many detailed reviews of Graphical User Interfaces (GUIs) for R available, which should you choose? It’s not too difficult to rate them based on the number of features they offer, so I’ll start there. Then, I’ll follow with a brief overview of each.

Click through for the criteria and results. Bob also has a link to the dataset for your own comparisons. H/T R-Bloggers.

Leave a Comment

PostgreSQL HOT Tables and TPC-C Workloads

Published 2026-08-05 by Kevin Feasel

Avinash Vallarapu tunes a PostgreSQL implementation of the TPC-C workload:

Vacuum is almost always presented as a pain point, a culprit, and an over exaggerated source of performance problems in PostgreSQL. The MVCC implementation in PostgreSQL is different from Oracle, SQL Server, MySQL or MariaDB, and that implementation introduces two requirements of its own, freezing transaction IDs, which is largely seamless, and clearing dead tuples through the various forms of vacuum. At the same time the PostgreSQL community is far ahead in minimizing the impact of vacuum. Each release has introduced enhancements substantial enough that most users never realize vacuum is something they could tune at all, and the list of vacuum specific improvements is long enough to deserve an article of its own. Among all of those optimizations, one of the most often missed is how to avoid the need for vacuuming in the first place. That is achievable most of the time, and it is not new.

Pavan Deolasee worked on the idea through 2006 and 2007 and authored the concept of the Heap Only Tuple, or HOT. Simon Riggs, Heikki Linnakangas, Tom Lane and many other PostgreSQL core team members and contributors have written a great deal of enhancement around it since. In this article we look at what PostgreSQL HOT updates actually are, how fillfactor decides whether they succeed, and how we identify which tables benefit. We then put it to the test with a HammerDB benchmark using the HammerDB TPROC-C workload against PostgreSQL 18.4, six 60-minute runs across three dataset sizes, and the improvement from correctly applied PostgreSQL HOT updates is substantial.

Read on for an overview of HOT tables and the results of this experiment.

Leave a Comment

How OR Predicates Affect Indexes

Published 2026-08-05 by Kevin Feasel

Dualcore DBA adds a clause:

We’ve created an index on both of the columns in the WHERE clause both of which are also in the SELECT list. As a reminder, non-clustered indexes implicitly include the clustered index key in the included columns even if we have not explicitly specified it and so with this in mind, our index fully covers our query. This index should be good for an index seek right? Let’s execute our query again:

This solution isn’t the only way to SQL Server to use a specific pair of indexes—you can also use the UNION operator to replace one OR, for example. And that usually resolves the issue without needing index hints.

Leave a Comment

Building Oracle’s Automatic Workload Repository in Postgres

Published 2026-08-05 by Kevin Feasel

Kellyn Gorman simulates some functionality:

Moving from Oracle to PostgreSQL means losing one of Oracle’s most-loved diagnostic tools: the Automatic Workload Repository (AWR). The good news? Most of AWR’s core capabilities – snapshot history, wait event sampling, Top SQL analysis, and buffer cache inspection – have direct, open-source equivalents in PostgreSQL.

This guide translates Oracle AWR concepts into practical PostgreSQL diagnostics using extensions like pg_profile, pg_wait_sampling, and pg_stat_statements – complete with runnable SQL you can apply to your own environment today.

Read on to see how.

Leave a Comment

Partitioning Very Large Tables Quickly

Published 2026-08-05 by Kevin Feasel

Michael J. Swart provides an update:

This is an update to my post last week Partitioning a Huge Table where I talk about taking an existing table and making it partitioned.

My largest complaint in that post was that it was difficult to do online because rebuilding a clustered index on a huge table required reading or writing a lot of data.
Also if I wanted to take advantage of partition switching, it was still tricky because it required adding a check constraint which also took a long amount of time.

Was there any way to adopt partitioned tables for huge tables without incurring a size-of-data operation? I invited people to leave their ideas in the comments. A reader who calls himself mmiike delivered.

Click through for the answer.

Leave a Comment

Spurious Correlations: The CRAN Package

Published 2026-08-04 by Kevin Feasel

Mauricio Vargas Sepulveda has released an R package:

The goal of spuriouscorrelations is to keep alive the amazing examples from Tyler Vigen. Unfortunately, as of 2023-10-09, the website is down as my students noticed. Therefore, I decided to use the snapshot from the Internet Wayback Machine to save the datasets from 2023-06-07.

Click through to see how you can re-live those old charts, using the example of “number of people who drowned by falling into a pool” versus “films Nicolas Cage appeared in” on an annual basis. H/T R-Bloggers.

Leave a Comment

DOP Non-Feedback

Published 2026-08-04 by Kevin Feasel

Rebecca Lewis tries to get some feedback:

In my DOP Feedback post last month, I shared something very frustrating. I had all the documented prerequisites for DOP Feedback in place. Query Store in READ_WRITE mode, DOP_FEEDBACK enabled at the database scope, Compatibility Level 160, MAXDOP set to 14, and a repeatable workload generating real parallelism waits — but the DOP feedback never fired. No dop_feedback_eligible_query event. No entries in sys.query_store_plan_feedback. Nothing.

I said I’d follow with a sequel when I found a workload that does become eligible, and then I’d compare it against the one that did not. Well. This is that sequel, but I still don’t have it. Today is honestly my fourth full-day of testing without triggering any DOP Feedback.

Click through to learn what doesn’t work. Or at least didn’t work for Rebecca.

Leave a Comment

Executing Arbitrary Code during SQL Server Database Restoration

Published 2026-08-04 by Kevin Feasel

Fabiano Amorim explains a reason for the July SQL Server patch cycle:

CVE-2026-47295 is a SQL Server vulnerability that lets a maliciously crafted database backup execute attacker-controlled code with sysadmin privileges during a routine RESTORE DATABASE operation.

The flaw lives in the internal replication cleanup procedure sys.sp_MSremovedbreplication_internal, which builds a dynamic procedure name from the restored database’s name using QUOTENAME(). Because the destination variable is only nvarchar(255), a carefully crafted database name — one packed with closing square brackets — causes the generated name to be silently truncated into a different, attacker-controlled procedure name.

SQL Server then executes that procedure under an elevated internal restore context. The proof of concept detailed in this article demonstrates full instance compromise: a restored backup creates a new SQL Server login and adds it to the sysadmin fixed server role, with no application input, no visible SQL injection syntax, and no chance for an administrator to review the database first.

As mentioned in my lead-in, the July 2026 SQL Server patches fix this vulnerability, so it’d be a good idea to install that and then check out what you could do to an unpatched instance.

Leave a Comment

Viewing Statistics a SQL Server Query Used

Published 2026-08-04 by Kevin Feasel

Dualcore DBA takes a look:

Something I have been making use of recently is the change in the way statistics that have been used to compile a plan are presented to us as SQL Server users. On a number of occasions I have needed to understand, or at least get some sense of, which statistics SQL Server has used to come up with some of its estimates, usually when troubleshooting a poor estimate. This information has been available to us for a while, but up until fairly recent (OK – define recent, I guess!) versions of SQL Server, it was a bit hidden.

Granted, “fairly recent” means “all of the SQL Server versions that no longer have official support.” But there’s a compatibility level factor at play as well, so click through to learn more.

Leave a Comment