Tuning · XB Field Notes

Partial indexes and writes

Tue, 15 Feb 2028 00:00:00 +0000

A partial index filters rows, not columns. An index on id WHERE status = 'open' stores identifiers for open rows; status decides membership without becoming the search key. That distinction matters when estimating maintenance: a column need not appear in the stored key to affect an update’s cost.

For a table dominated by closed orders, excluding that history can save substantial index space. It does not make closed rows free to write, guarantee faster queries, or remove the table’s vacuum work. Evaluate the smaller structure alongside the writes that keep it correct.

Membership answers which rows belong. Write cost also depends on changed keys, predicate-column dependencies and same-page HOT eligibility.

Separate membership from update cost

An inserted row outside the predicate needs no entry in this particular index. Predicate evaluation, table storage, other indexes, and ordinary transaction work remain. Moving a row into the subset creates an entry. Moving it out changes visible membership; obsolete row versions and index entries are reclaimed later, rather than necessarily disappearing physically at that moment.

Keeping membership unchanged is not enough to skip maintenance. An open order whose indexed identifier changes needs a new index entry. Even changing an unrelated note can require new entries when PostgreSQL cannot use a heap-only tuple, or HOT, update.

For PostgreSQL 18 B-tree indexes, HOT requires unchanged values in every column referenced by the table’s index definitions, including expressions and partial-index predicates, plus space for the new tuple on the same heap page. Changing status from closed to archived blocks HOT even though neither value satisfies this index. Changing only an unindexed note can qualify. Lower table fillfactor leaves room but is no guarantee; other indexes can independently block the optimization.

This rule is version- and index-method-sensitive. PostgreSQL 16 introduced an exception for summarizing indexes such as BRIN; those summaries may still need updating during HOT. That exception does not apply to the B-tree example here. Read the documentation for the deployed version before extrapolating update behavior.

Eligibility is separate from usefulness

The planner must prove that query conditions imply the partial predicate. An open-only index cannot by itself answer a request including closed orders. A generic plan for status = $1 lacks that proof; a custom plan can know the supplied value. Parameters elsewhere in a query with literal status = 'open' do not erase that fact.

An eligible index still competes on cost. A sequential scan can be sensible for a small table or broad result. Inspect estimates, actual rows, and buffers before blaming predicate spelling. A test that always demands one index name confuses a performance hypothesis with a correctness requirement.

When it breaks

A growing backlog can make the open subset large; frequent status changes can also erase expected write savings. Compare representative reads and transitions, rather than extrapolating from index size alone. Many overlapping partial indexes add planning and maintenance work. Review the whole index set before adding another slice or removing an apparently unused index, especially one enforcing uniqueness.

Check it quickly

Run both blocks in one fresh psql -X -v ON_ERROR_STOP=1 session on a disposable PostgreSQL 18 database with track_counts enabled. Historical review records report SQL checks on PostgreSQL 18.6 in socket-free single-user mode; the client/server connection path was not tested. The temporary table contains 20,000 rows, with 200 open; explicit names avoid guessing PostgreSQL’s generated index names.

BEGIN;
CREATE TEMP TABLE partial_cost_demo (
 id integer NOT NULL,
 status text NOT NULL,
 note integer NOT NULL
) WITH (fillfactor=50);
INSERT INTO partial_cost_demo
SELECT g, CASE WHEN g % 100 = 0 THEN 'open' ELSE 'closed' END, 0
FROM generate_series(1,20000) AS g;
CREATE INDEX cost_all_id ON partial_cost_demo (id);
CREATE INDEX cost_open_id ON partial_cost_demo (id) WHERE status='open';
ANALYZE partial_cost_demo;
SELECT pg_relation_size('cost_all_id') AS full_bytes,
 pg_relation_size('cost_open_id') AS partial_bytes;
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
SELECT id FROM partial_cost_demo WHERE status='open' ORDER BY id LIMIT 5;
SELECT id FROM partial_cost_demo WHERE status='open' ORDER BY id LIMIT 5;

Expect identifiers 100 through 500 in steps of 100. The partial index should occupy fewer bytes, without an exact one-percent size promise: page overhead matters. Record the chosen plan rather than asserting its shape. The full index supplies a same-key size comparison and remains a competing access path.

UPDATE partial_cost_demo SET note=1 WHERE id=100;
SELECT n_tup_upd, n_tup_hot_upd FROM pg_stat_xact_user_tables
WHERE relid='partial_cost_demo'::regclass;
UPDATE partial_cost_demo SET status='archived' WHERE id=101;
SELECT n_tup_upd, n_tup_hot_upd FROM pg_stat_xact_user_tables
WHERE relid='partial_cost_demo'::regclass;
SELECT count(*) FROM partial_cost_demo WHERE status='open';
ROLLBACK;

The transaction-local counters update continuously: total updates progress from one to two. The note update may increase the HOT count; the status change should not, despite unchanged predicate membership. The isolated run recorded counters of (1, 1), then (2, 1), and 200 open rows. Index sizes were 466,944 and 16,384 bytes, respectively; the chosen index-only scan still made five heap fetches. These are fixture observations, not universal expectations. Rollback removed the fixture. This separates HOT eligibility from subset size; temporary-table timings do not establish production WAL savings or sustained write throughput.

Sources

PostgreSQL 18 partial indexes, membership, implication, and excessive partial indexes, checked 2026-10-15.
PostgreSQL 18 HOT, update eligibility and page space, checked 2026-10-15.
PostgreSQL 18 HOT implementation notes, predicate-column dependencies and tuple chains, checked 2026-10-15.
PostgreSQL 16 release notes, BRIN exception introduced in version 16, checked 2026-10-15.
PostgreSQL 18 PREPARE, custom and generic plans, checked 2026-10-15.
PostgreSQL 18 statistics, transaction-local counters, checked 2026-10-15.
PostgreSQL 18 EXPLAIN, execution and buffer measurements, checked 2026-10-15.
PostgreSQL 18 size functions, main-fork relation size, checked 2026-10-15.

Autovacuum eligibility is separate from completion

Fri, 04 Feb 2028 00:00:00 +0000

A busy table produces obsolete versions at a rate its maintenance must accommodate. Lowering an autovacuum trigger can make that table eligible sooner, but eligibility is not completion. A worker must still reach the table, acquire the required locks, and finish enough useful cleanup before the backlog grows again. Measure that whole cycle instead of treating one configuration value as a throughput guarantee.

When it breaks

The normal update/delete trigger combines a fixed threshold with a scale factor multiplied by the estimated table population. PostgreSQL 18 also applies a maximum threshold when enabled. Insert-triggered vacuum and age-driven freezing have their own reasons to run. Looking only at one dead-tuple ratio misses those paths, and interpreting every vacuum as proof that the update/delete threshold fired can misdiagnose a table.

Reducing the threshold does not remove old snapshot retention or create more I/O capacity. More workers and less cost delay can increase resource competition with foreground requests. A dead-tuple estimate near zero at every instant is neither a realistic universal target nor sufficient evidence of good performance. The useful target is sustainable cleanup with acceptable growth, latency, and maintenance cost.

The 2050-to-150 arithmetic requires the effective cap disabled or at least 2050. Eligibility, automatic execution and useful completion remain separate; runtime is held.

Check it quickly

The exact background-worker integration was not rerun in this review. Its previous automatic-vacuum observation remains historical; manual or single-user vacuum would not reproduce it.

Use a disposable PostgreSQL 18 instance with autovacuum and statistics tracking enabled, available workers, and its normal one-minute database inspection interval. Run the script through a fresh psql -X -v ON_ERROR_STOP=1 connection. It waits up to 130 seconds for an actual automatic run; a timeout is a failed observation, not permission to claim success from a manual vacuum instead.

CREATE SCHEMA churn_demo;
CREATE TABLE churn_demo.jobs (id integer PRIMARY KEY,n integer)
 WITH (autovacuum_enabled=false,
 autovacuum_vacuum_threshold=50,
 autovacuum_vacuum_scale_factor=0.2);
INSERT INTO churn_demo.jobs SELECT g,0 FROM generate_series(1,10000) AS g;
SELECT pg_stat_force_next_flush();
VACUUM (ANALYZE) churn_demo.jobs;
UPDATE churn_demo.jobs SET n=1 WHERE id<=1000;
SELECT pg_stat_force_next_flush();
SELECT n_live_tup,n_dead_tup,vacuum_count,autovacuum_count
FROM pg_stat_user_tables WHERE relid='churn_demo.jobs'::regclass;
SELECT 50+0.2*reltuples AS old_threshold,50+0.01*reltuples AS new_threshold
FROM pg_class WHERE oid='churn_demo.jobs'::regclass;
ALTER TABLE churn_demo.jobs SET
 (autovacuum_enabled=true,autovacuum_vacuum_scale_factor=0.01);
DO $$
DECLARE deadline timestamptz := clock_timestamp()+interval '130 seconds';
BEGIN
 LOOP
 PERFORM pg_stat_clear_snapshot();
 EXIT WHEN (SELECT autovacuum_count>0 FROM pg_stat_user_tables
 WHERE relid='churn_demo.jobs'::regclass);
 IF clock_timestamp()>deadline THEN
 RAISE EXCEPTION 'no automatic vacuum observed within the experiment budget';
 END IF;
 PERFORM pg_sleep(0.25);
 END LOOP;
END $$;
SELECT pg_stat_clear_snapshot();
SELECT n_dead_tup,last_autovacuum IS NOT NULL AS ran,autovacuum_count>0 AS counted
FROM pg_stat_user_tables WHERE relid='churn_demo.jobs'::regclass;
SELECT count(*),count(*) FILTER (WHERE n=1) FROM churn_demo.jobs;
DO $$ BEGIN
 IF (SELECT count(*) FROM churn_demo.jobs)<>10000
 OR (SELECT count(*) FROM churn_demo.jobs WHERE n=1)<>1000 THEN
 RAISE EXCEPTION 'maintenance changed application data';
 END IF;
END $$;
DROP SCHEMA churn_demo CASCADE;

The table initially disables only its own routine autovacuum so setup and the controlled update complete first. Manual VACUUM ANALYZE establishes statistics and resets the insertion backlog before one thousand rows are updated. The explicit statistics-flush calls keep pending write counters from appearing after the manual maintenance estimate; they are laboratory synchronization, not a production tuning recommendation.

Before enabling the worker, expect estimated live and dead counts of ten thousand and one thousand, a manual-vacuum count of one, and an automatic-vacuum count of zero. Exact application counts are checked separately. With the specified fixed threshold of fifty, the old scale factor gives 2,050 and the smaller factor gives 150. This comparison requires the effective maximum threshold to be disabled or at least 2,050; a smaller configured cap changes the arithmetic.

One thousand obsolete versions exceed the new trigger. The script enables routine autovacuum and lowers only that table’s factor, then waits for its automatic counter to advance. The polling block clears cached statistics before checking, so it does not keep reading one old statistics snapshot. It performs no manual vacuum after enabling the worker.

The final statistics report zero estimated dead tuples, a populated automatic timestamp, and a positive automatic counter. Application data remain ten thousand rows, with exactly one thousand values updated to one. In the tested instance, the observed background run completed within the budget. The exact delay depends on scheduler timing and worker availability, so the script asserts the event and data rather than one elapsed duration.

Diagnose the limiting stage

If no automatic run appears, check effective table options, server autovacuum settings, statistics tracking, worker activity, and conflicting locks. A manual maintenance timestamp cannot stand in for last_autovacuum. If runs complete but obsolete versions remain, investigate long transactions and other visibility horizons. If removable versions accumulate faster than completed work, then examine capacity, cost throttling, and write patterns.

Changing the scale factor for a large hot table is often more targeted than changing every table’s settings. Record the old options, compare several representative workload periods, and watch file growth and application latency along with maintenance counters. Reset or revise the override when the workload changes. Run VACUUM outside a transaction block. Fixture deletion occurs only on success; errors can leave its schema and table options behind. The demonstration’s cleanup does not replace inspection; a real table needs its chosen settings maintained deliberately, and continued freezing protection even when its update traffic falls quiet.

Sources

PostgreSQL 18 autovacuum configuration, thresholds, scale factors, worker limits, and inspection intervals, checked 2026-10-15.
PostgreSQL 18 routine vacuuming, trigger formulas and distinct maintenance purposes, checked 2026-10-15.
PostgreSQL 18 cumulative statistics, manual versus automatic counters and cached statistics, checked 2026-10-15.
PostgreSQL 18 statistics function implementation, the flush helper used to synchronize fixture observations, checked 2026-10-15.

A slower query needs both a plan and a wait check

Mon, 31 Jan 2028 00:00:00 +0000

A formerly fast query can become slow with the same data, statistics, and access plan. Another transaction may hold a lock, the storage cache may be colder, or the application may wait before PostgreSQL even receives the statement. Rechecking the plan is useful, but it belongs inside a broader comparison of where the elapsed time went. Begin by distinguishing time spent doing work from time spent waiting to do it.

Keep a comparable baseline

Record the statement shape, representative parameter values, returned row count, relevant session settings, and whether the application uses a prepared statement. Different parameters can produce very different populations. A manual query with a literal may not reproduce a prepared statement’s generic plan. A different role or search path can also change which objects and permissions apply.

Inspect current activity while the slowdown is happening. pg_stat_activity can show an active query with a lock wait; active does not mean continuously consuming CPU. pg_blocking_pids identifies sessions currently blocking that backend. Visibility into other roles’ activity requires appropriate privileges, so missing details are not evidence that nothing is running. Use fresh autocommit observations rather than repeatedly reading a cached monitoring snapshot inside one long transaction.

When it breaks

Blindly running ANALYZE treats every slowdown as a stale-statistics problem. That can add maintenance work while leaving the actual blocker untouched. Likewise, building an index on a one-row table cannot release another transaction’s row lock. Accurate estimated rows and a tiny sequential scan can coexist with arbitrarily long application waits.

EXPLAIN ANALYZE is an execution, including for writes, and can itself block. A broad update copied from production is not a harmless inspection command. First inspect waiting and lock ownership; measure a safe fixture or a statement whose effects are understood. Do not terminate an unfamiliar transaction merely because its identifier appears in the blocker list.

A lock-free plan sample still does not equal end-to-end latency. EXPLAIN ANALYZE does not deliver ordinary result rows to the client; without SERIALIZE it also omits their output conversion. TIMING OFF reduces per-node timing overhead while retaining total execution timing. Large result transfer, application decoding, and pool queues therefore need observations outside this plan.

The multi-session story is attributed history with no recovered raw log. Printed observations need manual checks; timeout is a separate failure outcome.

Check it quickly

Open three fresh psql sessions, A, B, and C, using the same role and disposable PostgreSQL 18 database with normal autocommit enabled. The named schema must not already exist, and no other session in the cluster may use the fixture application name. Use a role allowed to create and remove the schema, with activity tracking enabled and no shorter lock timeout. Stop on unexpected errors in each session. Keep the session roles separate; pasting every block into one connection cannot demonstrate blocking between transactions.

In A, create the fixture, then begin a transaction that changes its only row without committing.

\set ON_ERROR_STOP on
CREATE SCHEMA query_recheck_demo;
CREATE TABLE query_recheck_demo.items (id integer PRIMARY KEY,value integer);
INSERT INTO query_recheck_demo.items VALUES (1,0);
ANALYZE query_recheck_demo.items;

BEGIN;
UPDATE query_recheck_demo.items SET value=10 WHERE id=1;
SELECT pg_backend_pid() AS blocker_pid;

In B, start the measured update. It waits until A ends its transaction or the sixty-second statement timeout expires.

SET application_name='xbcatm_recheck_waiter';
SET statement_timeout='60s';
EXPLAIN (ANALYZE, BUFFERS, TIMING OFF)
UPDATE query_recheck_demo.items SET value=value+1 WHERE id=1;

While B is waiting, run this in C, before the timeout. The test application name identifies B without exposing its complete query text.

SELECT pid,state,wait_event_type,wait_event,pg_blocking_pids(pid) AS blockers
FROM pg_stat_activity WHERE application_name='xbcatm_recheck_waiter';

In A, undo the uncommitted change and release its lock. Then collect B’s completed plan.

ROLLBACK;

After B finishes successfully, use C to verify the stored value and remove the fixture.

SELECT value FROM query_recheck_demo.items WHERE id=1;
DROP SCHEMA query_recheck_demo CASCADE;

The original PostgreSQL 18.6 article report, not rerun here and without a recovered raw multi-session log in the retained validation files, described B as active with wait_event_type=Lock, wait_event=transactionid, and A’s process identifier in blockers. The wait-event detail can depend on the exact contention; the blocking relationship is the central evidence. After A rolled back, B incremented the original zero to one. The report says the final query returned one and cleanup removed the schema. Manually check that C identifies exactly B, that its blockers contain A’s reported pid, and that the final value is one; the SQL prints these observations without asserting them.

B’s scan estimated and read one row. Its top Update node returned zero rows because there was no RETURNING clause, not because it changed nothing. Execution time includes the induced wait and depends on how quickly A releases it. If the timeout occurs first, roll back A and use C’s final block to remove the fixture before restarting. The canceled update did not complete its increment. Errors or interruption can leave A’s transaction and the permanent schema; end that transaction before removing this fixture schema.

Follow the observed cause

For a lock wait, investigate transaction lifetime and ownership before changing access paths. For excessive processed rows, compare selectivity and current statistics. For sorts or hashes that spill, inspect their memory and temporary I/O. Finally, compare database execution with application latency to expose connection or client delays. A new plan is meaningful only when it explains the measured regression and preserves the required result.

Sources

PostgreSQL 18: Monitoring database activity, active sessions and wait observations, checked 2026-10-15.
PostgreSQL 18: Using EXPLAIN, row counts and loops and plan interpretation, checked 2026-10-15.
PostgreSQL information functions, blocking-session identification with pg_blocking_pids, checked 2026-10-15.

VACUUM FULL rebuilds a table instead of pruning it

Mon, 03 Jan 2028 00:00:00 +0000

After a large deletion, a PostgreSQL table may retain a large file even when only a small fraction of its rows remain. Ordinary vacuum makes obsolete space reusable; VACUUM FULL rewrites the surviving contents into a new file and rebuilds indexes. That stronger reclamation has a different lock and capacity budget, so it belongs to planned maintenance rather than routine reaction to a large size number.

When it breaks

The rewrite takes an ACCESS EXCLUSIVE table lock. It conflicts with ordinary readers as well as writers, including a transaction that already finished its query but remains open while holding a table lock. Calling it an exclusive row lock, or assuming read traffic can continue, understates the outage risk. A queued rewrite can also affect later lock requests while it waits.

The old storage remains until replacement succeeds, so the operation needs additional disk space. Starting only when the filesystem is already full can remove the room needed to recover. Estimate the replacement table and indexes, I/O and WAL impact, and acceptable lock duration. Regular autovacuum does not automatically perform this rewrite.

VACUUM FULL needs a conflicting table lock and spare replacement space. The proposed SQLSTATE assertion remains unrun in two sessions; no production timing result is claimed.

Check it quickly

Earlier review records report only the setup and successful-compaction SQL portions in PostgreSQL 18.6 single-user mode. The two-session lock exercise remains unrun, and this source review ran no SQL.

For an authorized live test, open two fresh psql -X -v ON_ERROR_STOP=1 sessions, A and B, in the same disposable PostgreSQL 18 database. Save each B block in a file and load it with \i; any script error must stop the exercise. Run vacuum outside explicit transactions. B creates five thousand rows, deletes the first 4,500, and performs ordinary vacuum:

CREATE SCHEMA compact_demo;
CREATE TABLE compact_demo.items (id integer PRIMARY KEY,payload text)
 WITH (autovacuum_enabled=false);
INSERT INTO compact_demo.items
SELECT g,repeat(md5(g::text),10) FROM generate_series(1,5000) AS g;
CREATE TABLE compact_demo.baseline AS
SELECT pg_relation_size('compact_demo.items') AS heap_bytes,
 pg_relation_filenode('compact_demo.items') AS file_id;
DELETE FROM compact_demo.items WHERE id<=4500;
VACUUM (ANALYZE) compact_demo.items;
SELECT pg_relation_size('compact_demo.items')=heap_bytes AS same_heap_size,
 pg_relation_filenode('compact_demo.items')=file_id AS same_file
FROM compact_demo.baseline;

The two comparisons return true: heap bytes and the relation’s file identifier remain unchanged. The surviving rows occupy the tail, so ordinary vacuum cannot shrink this particular file by truncating an empty end. This does not establish that ordinary vacuum never shrinks files; empty trailing pages can be returned when truncation is possible.

In A, read the remaining five hundred rows and keep the transaction open:

BEGIN;
SELECT count(*) FROM compact_demo.items;

A has made no updates, but still holds its table lock. In B, give the rewrite a short acquisition budget so the demonstration does not wait indefinitely:

SELECT current_setting('lock_timeout') AS original_lock_timeout \gset
SET lock_timeout='100ms';
\set ON_ERROR_STOP off
VACUUM (FULL) compact_demo.items;
\set full_state :SQLSTATE
\set ON_ERROR_STOP on
SET lock_timeout = :'original_lock_timeout';
SELECT 1 / (:'full_state' = '55P03')::integer AS expected_lock_timeout;

Capture SQLSTATE immediately: restoring the timeout runs another query and would overwrite it. Only 55P03 makes the integer denominator one; unexpected success or another error causes division by zero under ON_ERROR_STOP. The assertion must return one after restoring B’s saved setting. A remains open until the next step, or must be released manually after failure. This proposed check is still unrun with concurrent sessions; the timeout is a laboratory value, not a production budget.

End the reader transaction in A:

COMMIT;

Now B can perform the rewrite, inspect storage identity, and verify every retained payload:

VACUUM (FULL,ANALYZE) compact_demo.items;
SELECT pg_relation_size('compact_demo.items')<heap_bytes AS smaller_heap,
 pg_relation_filenode('compact_demo.items')<>file_id AS different_file
FROM compact_demo.baseline;
SELECT count(*),min(id),max(id),sum(id),
 bool_and(payload=repeat(md5(id::text),10)) AS payloads_preserved
FROM compact_demo.items;
DO $$ BEGIN
 IF (SELECT sum(id) FROM compact_demo.items)<>2375250
 OR (SELECT count(*) FROM compact_demo.items)<>500
 OR EXISTS (SELECT FROM compact_demo.items
 WHERE payload<>repeat(md5(id::text),10)) THEN
 RAISE EXCEPTION 'compaction changed application data';
 END IF;
END $$;
DROP SCHEMA compact_demo CASCADE;

Both storage comparisons are true: the heap is smaller and its file identifier has changed. The data check returns five hundred rows, identifiers 4501 through 5000, an identifier sum of 2,375,250, and true payload preservation. The assertion checks the row population and content; a smaller file alone would not prove correct compaction. On success the fixture schema is removed. Earlier errors can leave it behind; release A’s transaction and inspect the disposable fixture before cleanup.

Decide whether compaction pays for itself

If future inserts will reuse the free space, keeping it inside the relation may be preferable to paying for a rewrite and later growing the file again. Measure persistent excess space and access cost after the workload settles. Distinguish the main heap from indexes and auxiliary storage, because a single table-size number may combine several objects with different causes of growth.

Schedule the operation where its exclusive lock is acceptable, and check for long-running readers before requesting it. A low-traffic period does not guarantee no open transaction exists. Set an intentional acquisition budget, observe failure rather than endlessly retrying, and verify data and storage afterward. Keep ordinary vacuum healthy so severe accumulation does not become the normal maintenance cycle.

The experiment demonstrates lock conflict, file replacement, and preserved rows on a small table. It does not predict rewrite duration or spare-space needs for a production table with large indexes, external values, or replication traffic. Those quantities require measurements from the actual object and a maintenance plan that can tolerate the resulting lock window.

Sources

PostgreSQL 18 VACUUM, rewrite behavior, extra space, truncation, and transaction restrictions, checked 2026-09-10.
PostgreSQL 18 explicit locking, ACCESS EXCLUSIVE conflicts with readers and writers, checked 2026-09-10.
PostgreSQL 18 routine vacuuming, routine reuse versus exceptional full compaction, checked 2026-09-10.
PostgreSQL 18 psql, SQLSTATE capture, variable interpolation and script error handling, checked 2026-10-19.
PostgreSQL 18 error codes, 55P03 lock_not_available identity, checked 2026-10-19.

Tuning · XB Field Notes

Partial indexes and writes

Separate membership from update cost

Eligibility is separate from usefulness

When it breaks

Check it quickly

Sources

Further reading

Autovacuum eligibility is separate from completion

When it breaks

Check it quickly

Diagnose the limiting stage

Sources

A slower query needs both a plan and a wait check

Keep a comparable baseline

When it breaks

Check it quickly

Follow the observed cause

Sources

VACUUM FULL rebuilds a table instead of pruning it

When it breaks

Check it quickly

Decide whether compaction pays for itself

Sources