From: | Victor Sudakov <vas(at)sibptus(dot)ru> |
---|---|
To: | pgsql-admin(at)lists(dot)postgresql(dot)org |
Cc: | Ron <ronljohnsonjr(at)gmail(dot)com> |
Subject: | Re: Large number of partitions of a table |
Date: | 2022-01-18 02:54:43 |
Message-ID: | YeYr88f3jXHlijU9@admin.sibptus.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
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(at)fidonet
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-01-18 04:30:13 | Re: Large number of partitions of a table |
Previous Message | Scott Ribe | 2022-01-17 17:37:52 | Re: Large number of partitions of a table |