Ron wrote: > On 1/16/22 11:38 PM, Victor Sudakov wrote: > > Tom Lane wrote: > > [dd] > > > >> The specific point that depesz was responding to in that blog > >> was the 64K-ish limit on rangetable entries in a query. That is > >> a thing, as he could have shown by using queries that weren't > >> amenable to plan-time pruning. (It's also an ex-thing, having > >> been fixed for v15 [1]; but that doesn't help you today.) > >> Now, if you use no queries that can't be pruned to a few > >> partitions, then it's academic for you. > > The table will be partitioned `BY LIST (customer_id)` which is a unique > > index. All queries will be using this index > > Good. > > > so no query should ever have to use more than 1 partition. > > I find it hard to believe that you'll *never* run a report against more > customers than are in a single partition. Thank you for raising this question, it can be of great interest. What's the worst thing to happen if someone runs "SELECT COUNT(*) FROM t" where t has 10000 partitions? 1. The backend will crash? 2. The whole cluster will crash? 3. Only this particular query (spanning multiple partitions) will be very slow? 4. ? Also, what if it is not a SELECT but an UPDATE query spanning multiple partitions? Does it make any difference? -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49@fidonet
