Re: unable to drop index because it does not exists - Mailing list pgsql-general

From Michael Lewis
Subject Re: unable to drop index because it does not exists
Date
Msg-id CAHOFxGrEE2_a3JCWwwXaBzrAYgf6UVdcUfoYwhkU+=N900yxXA@mail.gmail.com
Whole thread Raw
In response to Re: unable to drop index because it does not exists  (Luca Ferrari <fluca1978@gmail.com>)
List pgsql-general
Partition key: LIST (date_part('year'::text, mis_ora))

As an aside, you may benefit from switching to range partitioning* depending on how your queries are written. If you have conditions such as "WHERE mis_ora BETWEEN CURRENT_DATE - 30 AND CURRENT_DATE" or similar, then the fact that your partitioning is defined as a function result will mean all partitions gets scanned instead of partitioned being pruned as early as possible in the process. That's my understanding anyway. If you always include date_part( 'year', mis_ora) comparison in your where/join conditions, then you'll likely be just fine. Do as you need.

*eg '01/01/2018' to '01/01/2019' for the 2018 partition since upper bound is always exclusive

pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Pg_auto_failover
Next
From: Laurenz Albe
Date:
Subject: Re: Autovacuum lock conflict