Skip to content

Optimize vacuum/analyze - #81

Merged
serprex merged 8 commits into
mainfrom
optimize-analyze
Aug 6, 2026
Merged

Optimize vacuum/analyze#81
serprex merged 8 commits into
mainfrom
optimize-analyze

Conversation

@serprex

@serprex serprex commented Aug 3, 2026

Copy link
Copy Markdown
Member

Non-shape catalog updates can be applied without boundary

@serprex
serprex requested a review from harshil-goel August 3, 2026 23:56
serprex added 2 commits August 4, 2026 00:01
Non-shape catalog updates can be applied without boundary
Avoids 20ms stuttering while processing DDL
serprex added 4 commits August 4, 2026 17:22
Default is to have everything involved on EC2 to avoid local deviation

Remove probing based on row count, this was causing probe spam to obscure throughput.
Instead probes for latency are at a consistent period & throughput uses an alternative mechanism

@harshil-goel harshil-goel left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At some places i saw comments about laptop-rtt issues. Can you take a quick look and delete comments about old implementations?

Comment thread bench/ec2/ec2-bench/deploy.sh Outdated
pub const PG_CLASS_OID: u32 = 1259;
/// Catalogs that store statistics, including indexes and toast heaps
/// Keep `pg_statistic_ext` outside this list because DDL writes its definition
const OPAQUE_CATALOG_OIDS: &[u32] = &[

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could it change with postgres versions? Could there be more oids that we should capture? Is it possible to directly just see which tables get changed when ddl happens and track only them?

@serprex serprex Aug 6, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really. Postgres is pretty good about keeping OIDs constant <16384. This design is done as optimization so that if we miss things (or new PG version adds new stat table) we just get degraded perf rather than missing shape update

Been trying to keep this stuff simple, but maybe we'll need to have more fine grained tracking in future

Comment thread bench/src/lib.rs

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

count_all function in this file (i can't comment on the exact location here). is counting direct rows. running the benchmark again without clearing clickhouse would lead the benchmark overcounting. we would need distinct(id) or final.

@serprex serprex Aug 6, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should truncate beforehand, benchmarking on differently sized tables wouldn't be clean

(checked: we truncate)

@serprex
serprex requested a review from harshil-goel August 6, 2026 16:14
@serprex
serprex merged commit 4f5a9bf into main Aug 6, 2026
4 of 10 checks passed
@serprex
serprex deleted the optimize-analyze branch August 6, 2026 19:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants