Update PGD limitations - #6940
Conversation
| Because of many immediate risks and limitations, PGD 6 does not | ||
| officially support multiple databases on a single PostgreSQL | ||
| instance. A future release of PGD 6 may remove these risks and | ||
| limitations, but until then **we currently recommend a | ||
| one-database-per-instance configuration**. This best practice is also | ||
| reflected in our tooling, including the CLI and Connection Manager, | ||
| which are designed to work at the instance level. | ||
|
|
||
| It's best practice and we recommend that you configure only one database per PGD instance. | ||
| These immediate risks and current limitations include: |
There was a problem hiding this comment.
My opinion and recommendations:
- scratch any hints on plans for future from the docs. At best, it makes customers eagerly waiting, then impatient. At worst, it's going to be embarrassing for us and disappointing customers down the road.
- "does not support" contradicts the recommendation, IMO. Let's make it clearer. I wouldn't want any customer nor our field even attempting to try multiple databases on PGD.
- Scratch the entire "it's still possible to host up to 10 databases" and limitations section. It's not really possible.
For example, how does the Connection Manager "work at instance level"? What if a node that's currently a write leader (and the Connection Manager therefore routes traffic to "at instance level") isn't even part of another database's PGD cluster?
How about Lag Control? Would that work? I rather think it might be missing from the limitations.
Overall, I think "not supported, but we tell you how to work around it" is just inconsequent and unnecessarily creates a foot gun.
There was a problem hiding this comment.
Took another shot at it.
| SELECT count(*) FROM pg_largeobject; | ||
| ``` | ||
|
|
||
| ### Slow performance for tables without primary keys or unique constraints |
There was a problem hiding this comment.
I don't like this, as it's not this simple, for very small tables (common use for nonindexed tables) things can be actually faster without index, and on the other hand, replication of large update/delete query that affected millions of rows will be slow even with indexes, so we need bit more precise language and potentially 2 items for this
There was a problem hiding this comment.
Ok I have edited this section to clarify these different scenarios.
| the right order of commits. | ||
|
|
||
| - CLI integration assumes one database. | ||
| Because of many immediate risks and limitations, we currently |
There was a problem hiding this comment.
I think this makes sense, however we do allow for up to 10 dbs and sell that sometimes, but maybe at the current stage we can document it like this
There was a problem hiding this comment.
keeping it as it is for now then I guess
eatonphil
changed the title
5 participants
BDR-6956