Q1 :Il n'y a pas de limite explicite dans la documentation . En pratique, certaines opérations sont O(n) sur nombre de tables; attendez-vous à ce que les temps de planification augmentent et à des problèmes avec des choses comme l'autovacuum lorsque vous arrivez à plusieurs milliers ou dizaines de milliers de tables dans une base de données.
Q2 :Cela dépend de la requête. Généralement, les grands syndicats sont une mauvaise idée. L'héritage de table fonctionnera un peu mieux, mais si vous utilisez constraint_exclusion entraînera des temps de planification considérablement accrus.
Ces deux questions suggèrent un problème sous-jacent avec votre conception. Vous ne devriez pas avoir besoin un grand nombre de tables et des syndicats géants.
D'après le commentaire dans l'autre réponse, vous devriez vraiment créer quelques tables. Vous semblez vouloir créer une table par numéro de téléphone, ce qui n'a aucun sens, et créer des vues par numéro en plus de cela. Ne le faites pas, cela modélise mal les données et il sera plus difficile, et non plus facile, de travailler avec. Les index, les clauses where et les jointures vous permettront d'utiliser les données plus efficacement lorsqu'elles sont logiquement structurées en quelques tables. Je suggère d'étudier la modélisation relationnelle de base.
Si vous rencontrez des problèmes d'évolutivité ultérieurement, vous pouvez consulter le partitionnement , mais vous n'aurez pas besoin de milliers de tables pour cela.
