| From: | Michael Lewis <mlewis(at)entrata(dot)com> |
|---|---|
| To: | Luca Ferrari <fluca1978(at)gmail(dot)com> |
| Cc: | Ron <ronljohnsonjr(at)gmail(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: unable to drop index because it does not exists |
| Date: | 2019-09-23 17:49:32 |
| Message-ID: | CAHOFxGrEE2_a3JCWwwXaBzrAYgf6UVdcUfoYwhkU+=N900yxXA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2019-09-23 18:16:28 | Re: Autovacuum lock conflict |
| Previous Message | Adrian Klaver | 2019-09-23 17:41:16 | Re: Pg_auto_failover |