I tried removing the index from the part_master table and got the same
result
Since all the data is in the partitions, the part_master table is empty,
so the index is not useful for your query.
myDB=# explain SELECT min(logdate) FROM part_master;
Proposals :
1- Use plpgsql
Hi List;
I'm having some performance issues with a partitioned table. We have a
VERY large table that we've partitioned by day.
Currently we have 17 partitions - each partition table contains
700million rows.
One of the things we need to query is the min date from the master
table - we
kevin kempter wrote:
One of the things we need to query is the min date from the master table
- we may explore alternatives for this particular query, however even if
we fix this query I think we have a fundamental issue with the use of
indexes (actuallt the non-use) by the planner.
We had a
Hi List;
Sorry if this is a dupe, my first post never showed up...
I'm having some performance issues with a partitioned table. We have a
VERY large table that we've partitioned by day.
Currently we have 17 partitions - each partition table contains
700million rows.
One of the things we
kevin kempter wrote:
Hi List;
Sorry if this is a dupe, my first post never showed up...
I'm having some performance issues with a partitioned table. We have a
VERY large table that we've partitioned by day.
Unfortunately, that is the defined behavior in this case. From 5.9.6 of
the
kevin kempter [EMAIL PROTECTED] writes:
that the planner wants to do a sequential scan on each partition. We do have
constraint_elimination = on set in the postgresql.conf file.
constraint_exclusion btw.
myDB=# explain SELECT min(logdate) FROM part_master;
Er, yeah. Unfortunately this
