Re: Adding skip scan (including MDAM style range skip scan) to nbtree

Mark Dilger <mark.dilger@enterprisedb.com>

From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Masahiro Ikeda <ikedamsh@oss.nttdata.com>, Tomas Vondra <tomas@vondra.me>, Masahiro.Ikeda@nttdata.com, pgsql-hackers@lists.postgresql.org, Masao.Fujii@nttdata.com
Date: 2025-05-01T01:12:33Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. nbtree: Always set skipScan flag on rescan.

  2. meson: Build numeric.c with -ftree-vectorize.

  3. Fix "variable not found in subplan target lists" in semijoin de-duplication.

  4. Revert "nbtree: Remove useless row compare arg."

  5. nbtree: Remove useless row compare arg.

  6. Prevent premature nbtree array advancement.

  7. nbtree: tighten up array recheck rules.

  8. Avoid treating nonrequired nbtree keys as required.

  9. Adjust overstrong nbtree skip array assertion.

  10. Make NULL tuple values always advance skip arrays.

  11. Avoid extra index searches through preprocessing.

  12. Improve nbtree skip scan primitive scan scheduling.

  13. Further optimize nbtree search scan key comparisons.

  14. Add nbtree skip scan optimization.

  15. Improve nbtree array primitive scan scheduling.

  16. nbtree: Make BTMaxItemSize into object-like macro.

  17. Show index search count in EXPLAIN ANALYZE, take 2.

  18. Make parallel nbtree index scans use an LWLock.

  19. Show index search count in EXPLAIN ANALYZE.

  20. Avoid nbtree parallel scan currPos confusion.

  21. nbtree: Remove useless 'strat' local variable.

  22. Normalize nbtree truncated high key array behavior.

  23. Refactor handling of nbtree array redundancies.

  24. Fix nbtree pgstats accounting with parallel scans.

  25. Avoid parallel nbtree index scan hangs with SAOPs.

  26. Show Parallel Bitmap Heap Scan worker stats in EXPLAIN ANALYZE

  27. Enhance nbtree ScalarArrayOp execution.

  28. Skip checking of scan keys required for directional scan in B-tree

  29. Instead of using a numberOfRequiredKeys count to distinguish required

Attachments

Peter,

moving the conversation here from "pgsql: Improve nbtree skip scan
primitive scan scheduling" thread on -committers.  Attached is another
regression test for your consideration, which gives rise to the following
assertion:

TRAP: failed Assert("numSkipArrayKeys == 0"), File: "nbtpreprocesskeys.c",
Line: 1859, PID: 7210
0   postgres                            0x00000001032f30e0
ExceptionalCondition + 108
1   postgres                            0x0000000102e83100
_bt_preprocess_keys + 6036
2   postgres                            0x0000000102e87338 _bt_first + 168
3   postgres                            0x0000000102e84680 btgettuple + 196
4   postgres                            0x0000000102e75cdc
index_getnext_tid + 68
5   postgres                            0x00000001030017a0 IndexOnlyNext +
228
6   postgres                            0x0000000102fe5b2c ExecScan + 228
7   postgres                            0x0000000103011088 ExecSort + 536
8   postgres                            0x0000000102fdbc68
standard_ExecutorRun + 312
9   postgres                            0x00000001031bdfb8 PortalRunSelect
+ 236
10  postgres                            0x00000001031bdbd4 PortalRun + 492
11  postgres                            0x00000001031bcb18
exec_simple_query + 1292
12  postgres                            0x00000001031b9d1c PostgresMain +
1388
13  postgres                            0x00000001031b59a8
BackendInitialize + 0
14  postgres                            0x000000010310edd8
postmaster_child_launch + 372
15  postgres                            0x000000010311303c ServerLoop + 4948
16  postgres                            0x0000000103111360
InitProcessGlobals + 0
17  postgres                            0x0000000103030c00 help + 0
18  dyld                                0x000000018eb17154 start + 2476

This looks sufficiently different from the assertion mentioned on the other
thread to be worth posting here.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company