| From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
|---|---|
| To: | S Bob <sbob(at)quadratum-braccas(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: wide table, many many partitions, poor query performance |
| Date: | 2021-03-15 17:03:35 |
| Message-ID: | 20210315170334.GR29463@telsasoft.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, Mar 15, 2021 at 10:53:06AM -0600, S Bob wrote:
> We have a client that is running PostgreSQL 12, they have a table with 212
> columns and 723 partitions
>
> It seems the planning time is consumed by generating 723 sub plans
Is plannning time the issue ?
Please show diagnostic output. You can start from here:
https://wiki.postgresql.org/wiki/Slow_Query_Questions
> I suspect it's due to the fact that they are using hash based partitioning,
> example:
>
> CREATE TABLE rental_transaction_hash_p723 PARTITION OF rental_transaction
> FOR VALUES WITH (MODULUS 723, REMAINDER 723);
>
> Based on a strategy like this, queries will ALWAYS scan all partitions
> unless a hash value is specified as part of the query, correct? I suspect
> this is the issue... looking for confirmation, or feedback if i'm off base
You didn't say anything about the query, so: yes, maybe.
The partition strategy and key need to be selected to optimize the intended
queries. Hash partitioning is frequently a mistake.
See also:
https://www.postgresql.org/message-id/20200502140032.GI28974@telsasoft.com
https://www.postgresql.org/message-id/20200602173353.GB30144@telsasoft.com
--
Justin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2021-03-15 17:03:59 | Re: wide table, many many partitions, poor query performance |
| Previous Message | S Bob | 2021-03-15 16:53:06 | wide table, many many partitions, poor query performance |