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 t
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
"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. Unfortunat
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 manual
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
