When you use window functions in SQL, you can't filter their results directly in a WHERE or HAVING clause — that's a well‑known limitation across many databases. GBase 8a, the China‑domestically developed MPP database from GBASE, solves this elegantly with the QUALIFY clause. Let's break down how it works, what it can do, and where you need to be careful. DROP TABLE IF EXISTS emp; CREATE TABLE emp
As data grows, you'll likely need to add nodes to your existing GBase 8a MPP cluster without downtime. This hands‑on guide walks through the full process of adding a composite GNode to a running GBASE cluster. Existing cluster: A healthy GBase 8a cluster New node: A server with a static IP address configured Network: All nodes must be able to communicate with each other Stop services on all existi
By default, identifiers in GBase 8s are case‑insensitive: uppercase letters are silently treated as lowercase. Setting the environment variable DELIMIDENT=Y changes how double‑quoted identifiers behave, enabling case‑sensitive table and column names. Here's a demonstration and a deep dive into the option, as used in a gbase database. With DELIMIDENT=y exported, execute the following statements: ex
This section is the map for the rest of the book. The five stages introduced in the 1.1 chapter overview (parse, analyze/rewrite, plan, portal, execute) are traced here through the actual code: which functions implement each stage, and in what order they get called. The mechanics of each of the five stages are unpacked in later chapters. Here, only the skeleton matters: how a backend starts up, ho
PostgreSQL Internals · Chapter 1 Query Processing Suppose a client sends SELECT * FROM users WHERE id = 1. The path that single line travels before coming back as a result row is longer than you might expect. Inside the PostgreSQL backend, that SQL goes through a five-stage pipeline. Backend entry and dispatch. The backend receives the message from the client and decides which processing path it s
很多团队的网络监控并不算差。 链路可用率有、接口带宽有、CPU 和内存有、异常告警也接进了企业微信、飞书和短信。但真正出了事，复盘时还是会出现同一句话：当时知道出问题了，但没有把现场留住。 这就是为什么越来越多团队开始关注网络回溯分析系统。 它解决的不是“能不能看到告警”这个初级问题，而是更关键的两个问题： 告警发生时，能不能快速还原到底是哪一段流量、哪一条路径、哪一种会话出了问题 事故结束后，能不能基于证据复盘，而不是靠聊天记录和印象拼凑过程 对云上和混合云场景来说，这件事尤其重要。因为链路更长、设备更多、路径更动态，很多故障不是“持续坏”，而是短时抖动、瞬时拥塞、路径切换、策略误命中。如果没有回溯能力，排障就很容易沦为赛后猜谜。 这篇文章不讲空洞概念，直接从一线运维视角拆清楚：云上网络回溯分析系统到底该怎么建，应该覆盖哪些能力，落地时最容易踩哪些坑。 先说结论： 传统监控擅长发现“异常
Data is no longer treated as a byproduct of business operations and has become one of the most valuable organizational assets. Every interaction on a banking application, e-commerce platform, hospital system, logistics network or social media service generates data continuously. As organizations increasingly adopt digital workflows, cloud platforms, machine learning systems and real-time applicati
In modern data-driven organizations, managing and analyzing data efficiently is critical. OLAP (Online Analytical Processing) and OLTP (Online Transaction Processing) are both integral parts of data management, but they have different functionalities. Understanding how they differ, and how they complement each other is essential for anyone working with data systems. Online Transaction Processing (