kavirajk

package main

import (
	"context"
	"fmt"

	"github.com/ClickHouse/ch-go"
	"github.com/ClickHouse/ch-go/proto"
	"github.com/ClickHouse/clickhouse-go/v2"
)

kavirajk

package main

import (
	"fmt"
	"log"
	"time"

	"github.com/ClickHouse/clickhouse-go/v2"
)

kavirajk

// Minimal native-protocol client to observe the end-of-query packet-train
// stall (the "2xRTT" issue).
//
// It runs N identical SELECTs on ONE reused connection and, for each query,
// splits the client-observed latency into:
//
//	first_row : query sent -> first result row decoded  (the query itself)
//	tail      : first row  -> EndOfStream               (the epilogue train)
//
// A healthy query has tail ~= 0. When the epilogue train (profile info,

kavirajk

// Read-your-own-write: why "write a row, then read it back" takes 200ms+
// when the target is <20ms.
//
// End-to-end latency = write ack + visibility delay + read. With sync
// single-row inserts the write path drowns everything (scenario A - see the
// write repro for why). With async_insert + wait_for_async_insert=0 writes
// are ~ms and e2e is bounded by the VISIBILITY WINDOW: a row only becomes
// readable when the server flushes its async buffer, every
// async_insert_busy_timeout_ms (default 200). A write lands at a random
// point inside the window, so median e2e ≈ window/2 + one read (scenario B).

kavirajk

// Single-row inserts: why writing 100 rows/second (one INSERT each) shows
// 1s+ latency when a lone insert takes ~5ms.
//
// Two stacked causes:
//
//  1. Server-side: concurrent single-row INSERTs to one table convoy -
//     ~200ms each at concurrency 10, nearly zero CPU. This affects every
//     client (clickhouse-client too), even in-memory Buffer tables.
//  2. Client-side amplification: 100 writes/s x 0.2s each needs 20
//     connections in flight, but the driver default is MaxOpenConns=10 -

kavirajk

dle connections: why queries after an idle gap take ~2x longer.
//
// The clickhouse-go pool reuses one TCP connection for sequential queries:
// scenarios A and B below finish with dials=1 no matter how long the gaps
// are. Latency only doubles when the PEER (a load balancer, proxy, NAT box,
// or a server setting) closes connections that sit idle. Then every query
// finds a dead pooled connection and pays a reconnect - TCP handshake +
// protocol hello = 2 extra round trips (scenario C: dials == queries).
//
// The fix is in the environment, not the driver: find what closes idle

kavirajk

CREATE TABLE IF NOT EXISTS benchmark_test
(
    id    UInt64,
    value Array(Float64)
)
ENGINE = MergeTree
ORDER BY id;

INSERT INTO benchmark_test SELECT number, arrayMap(x -> rand64()/1e19, range(200)) FROM numbers(1000)

kavirajk

package main

import (
	"context"
	"fmt"

	"github.com/ClickHouse/clickhouse-go/v2"
)

func main() {

kavirajk

package main

import (
	"context"
	"crypto/tls"
	"fmt"
	"os"
	"sync"
	"time"

kavirajk

package main

import (
	"context"
	"fmt"

	"github.com/ClickHouse/clickhouse-go/v2"
)

func main() {