Repository navigation
Conversation
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
|
| Project | PgDog |
| Branch | murex-having-support |
| Testbed | Intel v1 |
Click to view all benchmark results
| Benchmark | Throughput | Benchmark Result operations / second (ops/s) x 1e3 (Result Δ%) | Lower Boundary operations / second (ops/s) x 1e3 (Limit %) | cpu-per-txn | Benchmark Result Measure (units) (Result Δ%) | Upper Boundary Measure (units) (Limit %) |
|---|---|---|---|---|---|---|
| lb-v3 | 📈 view plot 🚷 view threshold | 15.99 ops/s x 1e3(+0.00%)Baseline: 15.99 ops/s x 1e3 | 15.83 ops/s x 1e3 (99.00%) | 📈 view plot 🚷 view threshold | 42.02 units(+0.97%)Baseline: 41.62 units | 42.03 units (99.97%) |
|
| Project | PgDog |
| Branch | murex-having-support |
| Testbed | Intel v1 |
🐰 View full continuous benchmarking report in Bencher
⚠️ WARNING: Truncated view!The full continuous benchmarking report exceeds the maximum length allowed on this platform.
|
| Project | PgDog |
| Branch | murex-having-support |
| Testbed | Intel v1 |
🚨 1 Alert
| Benchmark | Measure Units | View | Benchmark Result (Result Δ%) | Upper Boundary (Limit %) |
|---|---|---|---|---|
| pooler-v3 | cpu-per-txn Measure (units) | 📈 plot 🚷 threshold 🚨 alert (🔔) | 40.95 units(+1.50%)Baseline: 40.35 units | 40.75 units (100.49%) |
Click to view all benchmark results
| Benchmark | Throughput | Benchmark Result operations / second (ops/s) x 1e3 (Result Δ%) | Lower Boundary operations / second (ops/s) x 1e3 (Limit %) | cpu-per-txn | Benchmark Result Measure (units) (Result Δ%) | Upper Boundary Measure (units) (Limit %) |
|---|---|---|---|---|---|---|
| pooler-v3 | 📈 view plot 🚷 view threshold | 16.99 ops/s x 1e3(-0.00%)Baseline: 16.99 ops/s x 1e3 | 16.82 ops/s x 1e3 (99.00%) | 📈 view plot 🚷 view threshold 🚨 view alert (🔔) | 40.95 units(+1.50%)Baseline: 40.35 units | 40.75 units (100.49%) |
|
Working on adjusting Bencher, please ignore those alerts for now |
0242c2a to
d39bcef
Compare
jkaczman
left a comment
There was a problem hiding this comment.
I also recommend adding HAVING to
(in ref. to #1802 (fix for #1795)), this code seems to add a case where it could propagate UnsupportedHaving off of
pgdog/pgdog/src/frontend/client/query_engine/route_query.rs
Lines 156 to 164 in eda06e8
and disconnect the client
|
@jkaczman addressed |
eaf189d to
b0566fb
Compare
|
| Project | PgDog |
| Branch | murex-having-support |
| Testbed | Intel v1 |
Click to view all benchmark results
| Benchmark | Throughput | Benchmark Result operations / second (ops/s) x 1e3 (Result Δ%) | Lower Boundary operations / second (ops/s) x 1e3 (Limit %) | cpu-per-txn | Benchmark Result Measure (units) (Result Δ%) | Upper Boundary Measure (units) (Limit %) | ctx-switches-per-txn | Benchmark Result Measure (units) (Result Δ%) | Upper Boundary Measure (units) (Limit %) |
|---|---|---|---|---|---|---|---|---|---|
| sharding-w2-v3 | 📈 view plot 🚷 view threshold | 10.00 ops/s x 1e3(+0.00%)Baseline: 10.00 ops/s x 1e3 | 9.90 ops/s x 1e3 (99.00%) | 📈 view plot 🚷 view threshold | 62.59 units(-0.07%)Baseline: 62.63 units | 63.26 units (98.94%) | 📈 view plot 🚷 view threshold | 1.27 units(+0.71%)Baseline: 1.26 units | 1.30 units (97.77%) |
4ca2dcc to
7f92f25
Compare
|
Metal bench failed. 3 of 150 measures outside bounds.
Counters per txn
Microbench: all 135 measures within bounds. Logslb, microbench, pooler, sharding-w2, sharding-w8, verdict.json |
|
What are your thoughts on splitting this into multiple stacked PRs? I think it'd help address some of the things I mentioned above as well as make it less likely for us to miss something. |
I am not sure if we can split the having feature itself into multiple PRs, but I can definitely separate out some refactoring that was done in this PR around |
…urex-having-support
|
Hmm.. how about this? Ideally each of these is less than 500 LOC.
|
jkaczman
left a comment
There was a problem hiding this comment.
I suggest splitting this up again due to it being over >1000 LOC, perhaps like this, although feel free to devise your own split if you have a better idea!
Execution (first)
- apply HAVING after merging shards' results
- don't wire in yet, continue to error from the prev stacked PR (re #1906)
- code:
parser/having.rsbuffer/having.rsBuffer::having()inbuffer.rsAggregateErrorvariants inaggregate/error.rsis_unsupported()inbackend/error.rsProjectionRewritePlan.havinginprojection.rs
- explicit unit tests to exercise all functionality via hand-built HAVING plan (extended upon with integration tests in planning)
Planning (second)
- rewrite the query sent to the shards
- wire in
Buffer::having(), remove error from prev stacked PR - code:
rewrite/statement/having.rsbuild()andfinalize_after_route()inprojection.rsBuffer::having()call inmulti_shard/mod.rsRoute::set_aggregate()inroute.rsAggregateFunction::from_builtin_name()inparser/aggregate.rs
- rewriter, query engine and integration tests
closes #695