Press "Enter" to skip to content

Day: August 5, 2026

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