Thanks Imre
On Wed., Jul. 24, 2019, 3:23 p.m. Imre Samu, wrote:
> > PostgreSQL 11.3 ... Total number of partition is 367 Partition
> key: LIST
>
> As I know:
> in PG11 "Declarative Partitioning Best Practices"
> *... " The query planner is generally able to handle partition hierarchies
> w
> PostgreSQL 11.3 ... Total number of partition is 367 Partition
key: LIST
As I know:
in PG11 "Declarative Partitioning Best Practices"
*... " The query planner is generally able to handle partition hierarchies
with up to a few hundred partitions fairly well, provided that typical
queries a
PostgreSQL 11.3 (Ubuntu 11.3-1.pgdg18.04+1) on x86_64-pc-linux-gnu,
compiled by gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0, 64-bit'
Total number of partition is 367
Parent table defination
Table "public.itinerary"
Column |Type | Collati
>*Can we know why this is happening?*
Please give us - more info about your system:
- PG version?
- number of partitions?
- any other important?
for example - in PG 11.2 Changes:
"Improve planning speed for large inheritance or partitioning table groups
(Amit Langote, Etsuro Fujita)"
https://www.
We encounter a issue when we do query on partition table directly with
proper partition key provide. postgres able to find problem partition but
when I do explain plan it showing 95% spend on planning the execution .
Here is example
itinerary=# EXPLAIN ANALYZE SELECT * FROM itinerary WHERE destinat
