- Notifications
You must be signed in to change notification settings - Fork4.9k
Commitebcf34d
committed
Fix performance hazard in REFRESH MATERIALIZED VIEW CONCURRENTLY.
Jeff Janes discovered that commit7ca25b7 made one of the queries run byREFRESH MATERIALIZED VIEW CONCURRENTLY perform badly. The root cause isbad cardinality estimation for correlated quals, but a principled solutionto that problem is some way off, especially since the planner lacks anystatistics about whole-row variables. Moreover, in non-error cases thisquery produces no rows, meaning it must be run to completion; but use ofLIMIT 1 encourages the planner to pick a fast-start, slow-completion plan,exactly not what we want. Remove the LIMIT clause, and instead rely onthe count parameter we pass to SPI_execute() to prevent excess work if thequery does return some rows.While we've heard no field reports of planner misbehavior with this query,it could be that people are having performance issues that haven't reachedthe level of pain needed to cause a bug report. In any case, that LIMITclause can't possibly do anything helpful with any existing version of theplanner, and it demonstrably can cause bad choices in some cases, soback-patch to 9.4 where the code was introduced.Thomas MunroDiscussion:https://postgr.es/m/CAMkU=1z-JoGymHneGHar1cru4F1XDfHqJDzxP_CtK5cL3DOfmg@mail.gmail.com1 parent7b544c4 commitebcf34d
1 file changed
+2
-2
lines changedLines changed: 2 additions & 2 deletions
Original file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
636 | 636 |
| |
637 | 637 |
| |
638 | 638 |
| |
639 |
| - | |
| 639 | + | |
640 | 640 |
| |
641 | 641 |
| |
642 |
| - | |
| 642 | + | |
643 | 643 |
| |
644 | 644 |
| |
645 | 645 |
| |
|
0 commit comments
Comments
(0)