059. Share repeated PostgreSQL flatmap parameter rows

  • Status: Implemented
  • Date: 2026-10-16

Problem and mechanism

A flatmap() callback can construct a list with repeated copies of one input parameter. Lowering each copy independently repeats the same row expansion and callback dependencies in generated SQL. For a bounded set of expressions, the PostgreSQL builder can validate the original constructor and then reuse one ordered row source for all copies.

The proof applies to a nonempty literal list or strict built-in concat() tree when every leaf is the same bare lexical parameter, identified by its binding identity. The builder does not compare SQL text or infer equivalence from types. It retains the first value descriptor and uses an ordinal source for repeated rows. Source order is preserved; ordinary null is repeated data, and a no-value parameter still fails the list. Constructor validation occurs before the shared source is selected.

Applicability

Callback list expression Status Reason
[v,v] for one bare parameter v Applied Both leaves share one lexical binding.
A strict built-in concat tree whose leaves are all v Applied The same parameter identity is reused across the tree.
[v[1],v[1]] or [v!,v!] Not applied The leaves are expressions, not bare parameter references.
Equal-looking expressions from distinct bindings Not applied SQL-text or descriptor equality is not a binding-identity proof.
Local backend Not applicable This is a PostgreSQL SQL-lowering choice.

Reproduction

The baseline is a8c9a6b. The candidate implementation accompanying this record is based on that revision. The public API generator uses Go 1.27.1 and emits parameterized WHERE SQL and ordered arguments for JSON and JSONB; it does not execute queries or measure runtime performance.

Save this program as /private/tmp/hff-repeated-flatmap-audit.go:

package main

import (
	"context"
	"encoding/json"
	"fmt"
	"os"
	"strings"

	"github.com/ornew/hff"
	sql "github.com/ornew/hff/backends/sql"
	"github.com/ornew/hff/capabilities"
	"github.com/ornew/hff/engine"
	"github.com/ornew/hff/schema"
)

func main() {
	e, err := engine.New(
		engine.WithSchema(schema.Struct(schema.Optional(schema.Nullable(
			schema.Map("labels", schema.NullableType(schema.BytesType)),
		)))),
		engine.WithCapabilities(capabilities.Standard()),
	)
	if err != nil {
		panic(err)
	}

	sources := []string{
		`labels:items:map(p=>p[1]):flatmap(v=>[v,v]):map(v=>v:type):json:exists`,
		`labels:items:flatmap(p=>[p[1],p[1]]):map(v=>v:type):json:exists`,
		`labels:items:map(p=>p[1]):flatmap(v=>[v]:concat([v])):map(v=>v:type):json:exists`,
		`labels:items:map(p=>p[1]):flatmap(v=>[v,v]):flatmap(v=>[v,v]):map(v=>v:type):json:exists`,
	}
	var results []map[string]any
	for _, format := range []sql.JSONFormat{sql.JSON, sql.JSONB} {
		for _, source := range sources {
			program, err := e.Compile(context.Background(), source)
			if err != nil {
				panic(err)
			}
			query, err := sql.Build(context.Background(), program,
				sql.WithDialect(sql.PostgreSQL),
				sql.WithBindings(sql.BindJSON(hff.Path{"labels"}, sql.Column("records", "labels"), format)),
			)
			if err != nil {
				panic(err)
			}
			results = append(results, map[string]any{
				"format": format,
				"source": source,
				"where":  query.Where(),
				"args":   query.Args(),
			})
			fmt.Fprintf(os.Stderr, "%s %dB %dargs %dunion %darray-sites %s\n",
				format, len(query.Where()), len(query.Args()),
				strings.Count(query.Where(), "UNION ALL"),
				strings.Count(query.Where(), "json_array_elements(")+strings.Count(query.Where(), "jsonb_array_elements("),
				source,
			)
		}
	}
	if err := json.NewEncoder(os.Stdout).Encode(results); err != nil {
		panic(err)
	}
}

Run it from the baseline and candidate checkouts:

# Baseline checkout.
GOTOOLCHAIN=go1.27.1 go run /private/tmp/hff-repeated-flatmap-audit.go \
  > /private/tmp/hff-repeated-flatmap-before.json \
  2> /private/tmp/hff-repeated-flatmap-before.log

# Candidate checkout.
GOTOOLCHAIN=go1.27.1 go run /private/tmp/hff-repeated-flatmap-audit.go \
  > /private/tmp/hff-repeated-flatmap-after.json \
  2> /private/tmp/hff-repeated-flatmap-after.log

The SQL-size observations use the same generator and fixtures at the baseline and candidate. Raw output is retained at /private/tmp/hff-repeated-flatmap-before.json and .log, and the matching after.json and .log files.

Results

WHERE byte counts are generated SQL size, not execution time:

JSON workload JSON baseline → candidate JSONB baseline → candidate
flatmap(v=>[v,v]) 7,552 → 5,820 7,558 → 5,826
flatmap(v=>[v]:concat([v])) 7,578 → 5,820 7,584 → 5,826
Two nested repeated flatmaps 13,139 → 6,962 13,145 → 6,968
Repeated p[1] expression control 8,069 → 8,069 8,075 → 8,075

Plain EXPLAIN (without ANALYZE) ran on PostgreSQL 18.6 with extra_float_digits=1, JIT disabled, and a 30-second statement timeout. The fixture was a records(labels) JSON row containing {"app":"YQ==","z":null} for both revisions. The plans for [v,v], [v]:concat([v]), and the two nested repeated flatmaps showed these plan-node counts, baseline → candidate:

Workload Function Scan Append Values Scan Materialize Aggregate
[v,v] 8 → 6 2 → 0 0 → 2 0 → 2 5 → 5
[v]:concat([v]) 8 → 6 2 → 0 0 → 2 0 → 2 5 → 5
Two nested repeated flatmaps 14 → 7 3 → 0 0 → 5 0 → 5 5 → 5

These plans still contain array scans and other work; the node counts do not establish execution counts or runtime improvement. The repeated p[1] expression control was not part of the plain-plan comparison.

Correctness and tradeoffs

The final selected PostgreSQL checks passed 178,618 logged query/record results across 380 groups, including 33,532 results for 19 typed fixtures in JSON and JSONB. Separate assertions passed 64 exact-output cases for multiplicity, order, indexing, folds, find(), distinct(), null, and no-value, plus 16 raw-Float boundary cases. Build tests retained 136 existing rejections in the candidate; the same rejections reproduced on the baseline with sharing disabled. Root unit, vet, integration vet, SQL race, and WASM checks passed. Logs are retained at /private/tmp/hff-repeat-corrected-pg.log and /private/tmp/hff-repeat-final-checks.log; this selected matrix is not a claim of full backend conformance.

The optimization is limited to copies of the same unchanged callback parameter. Indexed, guarded, method, and other computed expressions retain their existing lowering, even when they look equivalent. Full constructor validation and argument/cancellation behavior remain required. The repeated row source preserves list order and null elements; no-value remains a list failure. Performance evidence is limited to SQL shape; no benchmark or EXPLAIN ANALYZE result was collected.

Decision and limits

Use the shared row source only for the lexical-identity proof above. This does not cover duplicated slot expressions such as [p[1],p[1]] or computed branches. Equal-looking values from distinct lexical bindings do not share the proof; a captured parameter qualifies only when every leaf refers to that same binding. General branch sharing across arbitrary transformations retains the ordinary path unless it independently meets the proof.

Explore HFF
Search documentation

Search the language specification and guides.