|
564 | 564 | </para>
|
565 | 565 |
|
566 | 566 | <para>
|
567 |
| - As a rule of thumb, <structfield>queryid</structfield> values can be assumed to be |
568 |
| - stable and comparable only so long as the underlying server version and |
569 |
| - catalog metadata details stay exactly the same. Two servers |
570 |
| - participating in replication based on physical WAL replay can be expected |
571 |
| - to have identical <structfield>queryid</structfield> values for the same query. |
572 |
| - However, logical replication schemes do not promise to keep replicas |
573 |
| - identical in all relevant details, so <structfield>queryid</structfield> will |
574 |
| - not be a useful identifier for accumulating costs across a set of logical |
575 |
| - replicas. If in doubt, direct testing is recommended. |
| 567 | + Two servers participating in replication based on physical WAL replay can |
| 568 | + be expected to have identical <structfield>queryid</structfield> values for |
| 569 | + the same query. However, logical replication schemes do not promise to |
| 570 | + keep replicas identical in all relevant details, so |
| 571 | + <structfield>queryid</structfield> will not be a useful identifier for |
| 572 | + accumulating costs across a set of logical replicas. |
| 573 | + If in doubt, direct testing is recommended. |
| 574 | + </para> |
| 575 | + |
| 576 | + <para> |
| 577 | + Generally, it can be assumed that <structfield>queryid</structfield> values |
| 578 | + are stable between minor version releases of <productname>PostgreSQL</productname>, |
| 579 | + providing that instances are running on the same machine architecture and |
| 580 | + the catalog metadata details match. Compatibility will only be broken |
| 581 | + between minor versions as a last resort. |
576 | 582 | </para>
|
577 | 583 |
|
578 | 584 | <para>
|
|
0 commit comments