Commit e63deae
committed
Make sure we're using indexes during rollbacks
Fixes #2083
The `queryMinRefId` query uses
```sql
SELECT id FROM <table> WHERE <field> >= $1 ORDER BY id ASC LIMIT 1.
```
The planner sometimes picks a bad plan:
```sql
Index Scan using tx_pkey on tx
Filter: (block_id >= $1)
```
the filter is not Index Cond, so this ends up in a sequential scan.
The index refers to the primary key and is only used for sorting.
Instead we use a simpler query without ORDER BY:
SELECT id FROM <table> WHERE <field> >= $1 LIMIT 10000
This forces the planner to use the field's index.
The results are fetched and the minimum is found in Haskell.
Near the tip this returns only a handful of rows.
If there are more than 10000 matching rows (large rollback),
we fall back to the original ORDER BY id ASC LIMIT 1 query.1 parent cb61094 commit e63deae
1 file changed
Lines changed: 41 additions & 2 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
581 | 581 | | |
582 | 582 | | |
583 | 583 | | |
| 584 | + | |
| 585 | + | |
| 586 | + | |
| 587 | + | |
| 588 | + | |
| 589 | + | |
| 590 | + | |
| 591 | + | |
| 592 | + | |
| 593 | + | |
| 594 | + | |
| 595 | + | |
| 596 | + | |
| 597 | + | |
| 598 | + | |
| 599 | + | |
| 600 | + | |
| 601 | + | |
| 602 | + | |
| 603 | + | |
| 604 | + | |
| 605 | + | |
| 606 | + | |
| 607 | + | |
| 608 | + | |
| 609 | + | |
| 610 | + | |
| 611 | + | |
| 612 | + | |
| 613 | + | |
| 614 | + | |
| 615 | + | |
| 616 | + | |
| 617 | + | |
| 618 | + | |
| 619 | + | |
| 620 | + | |
| 621 | + | |
| 622 | + | |
584 | 623 | | |
585 | 624 | | |
586 | 625 | | |
| |||
589 | 628 | | |
590 | 629 | | |
591 | 630 | | |
592 | | - | |
| 631 | + | |
593 | 632 | | |
594 | 633 | | |
595 | 634 | | |
596 | 635 | | |
597 | 636 | | |
598 | | - | |
| 637 | + | |
599 | 638 | | |
600 | 639 | | |
601 | 640 | | |
| |||
0 commit comments