- Notifications
You must be signed in to change notification settings - Fork5
Commitd4b5d4c
committed
pgstattuple: Don't take heavyweight locks when examining a hash index.
It's currently necessary to take a heavyweight lock when scanning ahash bucket, but pgstattuple only examines individual pages, so itdoesn't need to do this. If, for some hypothetical reason, it didneed to do any heavyweight locking here, this logic would probablystill be incorrect, because most of the locks that it is taking aremeaningless. Only a heavyweight lock on a primary bucket page has anymeaning, but this takes heavyweight locks on all pages regardless offunction - and in particular overflow pages, where you might imaginethat we'd want to lock the primary bucket page if we needed to lockanything at all.This is arguably a bug that has existed since this code was added incommitdab4238, but I'm not going tobother back-patching it because in most cases the only consequence isthat running pgstattuple() on a hash index is a little slower than itotherwise might be, which is no big deal.Extracted from a vastly larger patch by Amit Kapila which heavyweightlocking for hash indexes entirely; analysis of why this can be doneindependently of the rest by me.1 parent33839b5 commitd4b5d4c
1 file changed
+0
-2
lines changedLines changed: 0 additions & 2 deletions
Original file line number | Diff line number | Diff line change | |
---|---|---|---|
| |||
441 | 441 |
| |
442 | 442 |
| |
443 | 443 |
| |
444 |
| - | |
445 | 444 |
| |
446 | 445 |
| |
447 | 446 |
| |
| |||
472 | 471 |
| |
473 | 472 |
| |
474 | 473 |
| |
475 |
| - | |
476 | 474 |
| |
477 | 475 |
| |
478 | 476 |
| |
|
0 commit comments
Comments
(0)