Skip to main content
Pinega
Use dark theme Menu

Pinega Research

Research is part of the product boundary, not a marketing appendix.

Pinega studies database systems where correctness, concurrency, performance, and failure semantics interact. Claims remain traceable to sources, models, experiments, implementation evidence, and unresolved questions.

READMODELVERIFYIMPLEMENTMEASURE

Research-area catalogue

Seven connected areas feed Pinega technology programmes.

The catalogue establishes stable ownership for current and future work without pretending that every area already has a public paper, experiment, or product.

Active

Storage and execution

MVCC layouts, Table AM integration, buffer management, indexing, vectorised visibility, and later analytical storage.

Active

Concurrency and memory reclamation

Atomic publication, ABA prevention, stable handles, helping, pins, HP, EBR/QSBR/RCU, and process-safe reclamation.

Active

Transactions and correctness

MVCC, serializability, SSI, SSN/ESSN, dependency graphs, anomalies, and PostgreSQL compatibility.

Programme

Distributed systems

Replication, consensus, clocks, distributed transactions, failure models, MPP execution, and one-copy correctness.

Active

Query optimisation and AI

Cardinality, decorrelation, rewrites, materialised views, recursive queries, MCTS/RL join ordering, and edge inference.

Active

Performance engineering and hardware

Cache coherence, NUMA, false sharing, per-CPU sharding, batching, SIMD/AVX-512, NVM, SSD, and ZNS.

Platform

Verification and deterministic testing

Linearizability, memory models, executable specifications, stress schedules, trace capture, and visual evidence.

YDMP Research Workspace

A workflow that preserves uncertainty and provenance.

External sources, learner interpretations, canonical models, verification ledgers, experiments, and implementation claims remain separate artefacts.

Capture

Record questions, answers, corrections, source scope, and reading frontiers without rewriting history.

Canonical model

Consolidate definitions, invariants, examples, dependencies, and accepted project decisions.

Verification ledger

Track confirmed, inferred, external, contradicted, experimental, and unresolved claims explicitly.

Active study 01

Versioned OLTP storage

The mutable store is being designed around out-of-place row versions and explicit visibility metadata rather than an implicit update-in-place abstraction.

  • Version chains and stable handles
  • Snapshot-compatible visibility rules
  • SIMD-oriented metadata evaluation
  • Garbage collection and space reuse as separate protocols

Open hypothesis

Separating version metadata from tuple payloads may enable faster visibility scans, but layout and cache costs must be measured on real PostgreSQL workloads.

Shared semantic model

Snapshot selection over a newest-to-oldest version chain

The current figure remains a validated cross-renderer specimen. No new diagram family is introduced by the Web IA milestone.

Newest-to-oldest row-version chainThe row head points to version v42, then v41, then v40. Version v42 contains balance 120, was created by transaction T42, has no deleting transaction, generation 42, and is visible to snapshot S17. Version v41 contains balance 100, was created by T41 and superseded by T42. Version v40 contains balance 80, was created by T40, superseded by T41, and has been retired but not yet reused. Snapshot S17 selects v42 because T42 committed before the snapshot.
A stable row head publishes the newest committed version; snapshot S17 selects v42 while older versions remain linked for other snapshots and later reclamation.
Text representation and semantic model
Newest-to-oldest row-version chain
stable row head: v42 → v41 → v40
v42: balance = 120; xmin=T42; xmax=—; generation=42; state=visible; selected by S17
v41: balance = 100; xmin=T41; xmax=T42; generation=41; state=obsolete; kept for older snapshots
v40: balance = 80; xmin=T40; xmax=T41; generation=40; state=retired; unlinked only after visibility permits
Snapshot S17 → v42: T42 committed before the snapshot
Download semantic model

Active study 02

Concurrent object lifetimes and reclamation

01Publish

Make a candidate visible with an explicit memory-order contract.

02Protect

Acquire a lifetime guard or pin before dereferencing shared state.

03Revalidate

Confirm identity and generation after protection.

04Retire

Separate logical deletion and physical unlinking from reuse.

05Reclaim

Free or reuse storage only after all protections are gone.

Executable lifecycle model

Publication, withdrawal, quiescence, and generation-safe reuse

The diagram distinguishes logical state changes from the later point at which storage becomes safe to reuse.

Buffer-frame publication and reclamation lifecycleThe buffer frame begins free, is reserved with a new generation, becomes valid after initialization and release publication, enters eviction after its mapping is removed and new pins are blocked, becomes retired while existing protectors drain, becomes reclaimable when no pins or hazard protections remain, and finally returns to free with another generation increment.
A frame can be reused only after publication has been withdrawn, identity revalidation can no longer succeed, and every lifetime protection has disappeared.
Text representation and semantic model
Buffer-frame publication and reclamation lifecycle
initial: Free
Free --claim slot [generation++]--> Reserved
Reserved --publish identity [store-release]--> Valid
Valid --begin eviction [remove mapping]--> Evicting
Evicting --retire generation [no new pins]--> Retired
Retired --observe quiescence [protectors = 0]--> Reclaimable
Reclaimable --reuse storage [generation++]--> Free
Download semantic model

Active study 03

Concurrent histories as explicit data

Calls, responses, real-time precedence, candidate linearization points, and sequential witnesses are stored independently from either renderer.

Overlapping queue operations and a legal linearizationThree thread lanes share a time axis. Thread P enqueues x from time 0.8 to 4.7 and linearizes at 2.3. Thread Q dequeues x from time 1.6 to 5.9 and linearizes at 3.6. Thread R enqueues y from time 6.2 to 7.7 and linearizes at 6.8. The first two operations overlap; both precede the third in real time. The legal sequential witness is enqueue x, dequeue x, enqueue y.
Two overlapping operations may be ordered at internal linearization points; a later enqueue must remain after both completed calls in real time.
Text representation and semantic model
Overlapping queue operations and a legal linearization
Thread P: inv enq(x) @0.8 → ok @4.7; LP @2.3
Thread Q: inv deq() @1.6 → x @5.9; LP @3.6
Thread R: inv enq(y) @6.2 → ok @7.7; LP @6.8
marker @6: quiescent cut
precedence: enq-x → enq-y (real-time precedence)
precedence: deq-x → enq-y
legal witness: enq-x → deq-x → enq-y
Download semantic model

Research outputs

The catalogue will grow by adding real artefacts, not empty route placeholders.

Source material

Papers, standards, official documentation, source code, tests, release notes, datasets, and benchmark specifications.

Pinega artefacts

Preparation packets, captured sessions, canonical models, verification ledgers, diagrams, prototypes, tests, and measured results.

Unresolved work

Gaps, competing designs, falsifiable hypotheses, risk registers, and proposed implementation milestones.

Inspect the boundary

Technology consumes research; documentation exposes reproducible work.

The next publishing gates will add real project, paper, experiment, and blog indexes on top of this taxonomy.

Technology programmesDocumentation