postgresql11.1 - stabilize partition pruning at execution time

From: Aliza Abulafia <Aliza(dot)Abulafia(at)Amdocs(dot)com>
To: "pgsql-admin(at)lists(dot)postgresql(dot)org" <pgsql-admin(at)lists(dot)postgresql(dot)org>
Cc: "Eli Cohen (ELCOHEN)" <Eli(dot)Cohen(at)amdocs(dot)com>
Subject: postgresql11.1 - stabilize partition pruning at execution time
Date: 2019-03-04 13:24:01
Message-ID: AM6PR06MB4567C24143A770A85E732898E6710@AM6PR06MB4567.eurprd06.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Subject: postgresql11.1 - stabilize partition pruning at execution time<https://stackoverflow.com/questions/54984175/postgresql11-1-stabilize-partition-pruning-at-execution-time>

Hi,

we are evaluating postgresql11.1 for our productions, trying to use partitions to ease vacuum work,
(we have a system with 4251 updates per second, ~1000 delete per second and ~3221 inserts per second and 1billion transaction per day). we face a problem, that partition pruning is not working steadily with updates although we have: 1) part_key=value at our "where" clause 2) enable_partition_pruning = 'on'. we understood that there is a new patch at 11, that is supposed to support ( Faster Partition Pruning + Partition Pruning at Execution Time)

how can we stable partition pruning?, how to identify the reason when it does not work? what parameters affect it? appreciate if someone has experience with this.

thanks in advance, Aliza.

This email and the information contained herein is proprietary and confidential and subject to the Amdocs Email Terms of Service, which you may review at https://www.amdocs.com/about/email-terms-of-service <https://www.amdocs.com/about/email-terms-of-service>

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Ron 2019-03-04 16:26:12 Re: postgresql11 space reuse under high delete/update rate
Previous Message Aliza Abulafia 2019-03-04 10:53:51 postgresql11 space reuse under high delete/update rate