Minor, and a judgement call rather than a clear defect — filing rather than patching because the right answer depends on what you intend the field to mean.
EXPLAIN reports the same pushdown count whether or not pushdown is enabled:
SET pgcolumnar.enable_qual_pushdown = on;
Rows Removed by Filter: 999
Columnar Pushed-Down Filters: 1
SET pgcolumnar.enable_qual_pushdown = off;
Rows Removed by Filter: 199999 <- the setting plainly works
Columnar Pushed-Down Filters: 1 <- but the report does not say so
200,000 rows, chunk_group_row_limit = 1000, one matching row.
The setting itself is fine. columnar_enable_qual_pushdown gates columnar_build_predicates in the reader, and the effect is exactly as advertised — 999 rows examined against 199,999. I checked that first, because after the bloom finding on #155 my prior was that a setting might not be wired to anything.
What is off is only the reporting. cstate->nScanKeys is the count the planner handed to the scan, so the number is true of the planner and not of the run: with the setting off, nothing is pushed down in any sense the reader acts on. Someone turning the setting off to test a theory, then checking EXPLAIN to confirm it took effect, is told it did not.
Two defensible readings, which is why this is a question rather than a patch:
- the field describes the plan — then it is correct as it stands, and the fix is a doc line saying so
- the field describes what the scan will do — then it should report 0 when the setting is off, in
columnar_customscan.c:1055 and columnar_vector.c:1482
I lean to the second, because every other Columnar ... line in that output describes the run rather than the plan (Projected Columns, Chunk Groups Total, and the counters below them), so this one line silently means something different from its neighbours. But it is your call and it is one line either way.
Found while auditing whether each setting does what its name says, after enable_bloom_filter turned out not to. Everything else checked out: enable_custom_scan, enable_vectorization, enable_index_only_scan, compression, stripe_row_limit, chunk_group_row_limit and enable_unique_insert_lock all change behaviour in the direction claimed. enable_end_truncation I could not exercise — it gates pgcolumnar.truncate(), defaults off, and pgcolumnar.vacuum already returns the file to its two-block minimum, so there was nothing left at the end to truncate. Reaching it looks like it needs columnar_debug_advance_reserved_offset, and I did not want to report a clean result I had not actually produced.
Minor, and a judgement call rather than a clear defect — filing rather than patching because the right answer depends on what you intend the field to mean.
EXPLAINreports the same pushdown count whether or not pushdown is enabled:200,000 rows,
chunk_group_row_limit = 1000, one matching row.The setting itself is fine.
columnar_enable_qual_pushdowngatescolumnar_build_predicatesin the reader, and the effect is exactly as advertised — 999 rows examined against 199,999. I checked that first, because after the bloom finding on #155 my prior was that a setting might not be wired to anything.What is off is only the reporting.
cstate->nScanKeysis the count the planner handed to the scan, so the number is true of the planner and not of the run: with the setting off, nothing is pushed down in any sense the reader acts on. Someone turning the setting off to test a theory, then checkingEXPLAINto confirm it took effect, is told it did not.Two defensible readings, which is why this is a question rather than a patch:
columnar_customscan.c:1055andcolumnar_vector.c:1482I lean to the second, because every other
Columnar ...line in that output describes the run rather than the plan (Projected Columns,Chunk Groups Total, and the counters below them), so this one line silently means something different from its neighbours. But it is your call and it is one line either way.Found while auditing whether each setting does what its name says, after
enable_bloom_filterturned out not to. Everything else checked out:enable_custom_scan,enable_vectorization,enable_index_only_scan,compression,stripe_row_limit,chunk_group_row_limitandenable_unique_insert_lockall change behaviour in the direction claimed.enable_end_truncationI could not exercise — it gatespgcolumnar.truncate(), defaults off, andpgcolumnar.vacuumalready returns the file to its two-block minimum, so there was nothing left at the end to truncate. Reaching it looks like it needscolumnar_debug_advance_reserved_offset, and I did not want to report a clean result I had not actually produced.